idnits 2.17.00 (12 Aug 2021) /tmp/idnits57097/draft-ietf-6lo-use-cases-11.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 35 instances of too long lines in the document, the longest one being 4 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 12, 2021) is 313 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: draft-ietf-6lo-blemesh has been published as RFC 9159 == Outdated reference: A later version (-11) exists of draft-ietf-6lo-plc-06 Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 6Lo Working Group Y-G. Hong 3 Internet-Draft Daejeon University 4 Intended status: Informational C. Gomez 5 Expires: January 13, 2022 UPC 6 Y-H. Choi 7 ETRI 8 AR. Sangi 9 Huaiyin Institute of Technology 10 S. Chakrabarti 11 July 12, 2021 13 IPv6 over Constrained Node Networks (6lo) Applicability & Use cases 14 draft-ietf-6lo-use-cases-11 16 Abstract 18 This document describes the applicability of IPv6 over constrained 19 node networks (6lo) and provides practical deployment examples. In 20 addition to IEEE Std 802.15.4, various link layer technologies such 21 as ITU-T G.9959 (Z-Wave), Bluetooth Low Energy, DECT-ULE, MS/TP, NFC, 22 and PLC are used as examples. The document targets an audience who 23 would like to understand and evaluate running end-to-end IPv6 over 24 the constrained node networks for local or Internet connectivity. 26 Status of This Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at https://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on January 13, 2022. 43 Copyright Notice 45 Copyright (c) 2021 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (https://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 61 2. 6lo Link layer technologies . . . . . . . . . . . . . . . . . 4 62 2.1. ITU-T G.9959 . . . . . . . . . . . . . . . . . . . . . . 4 63 2.2. Bluetooth LE . . . . . . . . . . . . . . . . . . . . . . 4 64 2.3. DECT-ULE . . . . . . . . . . . . . . . . . . . . . . . . 5 65 2.4. MS/TP . . . . . . . . . . . . . . . . . . . . . . . . . . 5 66 2.5. NFC . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 67 2.6. PLC . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 68 2.7. Comparison between 6lo link layer technologies . . . . . 8 69 3. Guidelines for adopting IPv6 stack (6lo) . . . . . . . . . . 9 70 4. 6lo Deployment Scenarios . . . . . . . . . . . . . . . . . . 11 71 4.1. Wi-SUN usage of 6lo in network layer . . . . . . . . . . 11 72 4.2. Thread usage of 6lo in network layer . . . . . . . . . . 12 73 4.3. G3-PLC usage of 6lo in network layer . . . . . . . . . . 13 74 4.4. Netricity usage of 6lo in network layer . . . . . . . . . 14 75 5. 6lo Use Case Examples . . . . . . . . . . . . . . . . . . . . 15 76 5.1. Use case of ITU-T G.9959: Smart Home . . . . . . . . . . 15 77 5.2. Use case of Bluetooth LE: Smartphone-based Interaction . 16 78 5.3. Use case of DECT-ULE: Smart Home . . . . . . . . . . . . 16 79 5.4. Use case of MS/TP: Building Automation Networks . . . . . 17 80 5.5. Use case of NFC: Alternative Secure Transfer . . . . . . 18 81 5.6. Use case of PLC: Smart Grid . . . . . . . . . . . . . . . 18 82 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 83 7. Security Considerations . . . . . . . . . . . . . . . . . . . 19 84 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 20 85 9. Informative References . . . . . . . . . . . . . . . . . . . 20 86 Appendix A. Design Space Dimensions for 6lo Deployment . . . . . 26 87 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 27 89 1. Introduction 91 Running IPv6 on constrained node networks presents challenges, due to 92 the characteristics of these networks such as small packet size, low 93 power, low bandwidth, low cost, and large number of devices, among 94 others [RFC4919][RFC7228]. For example, many IEEE Std 802.15.4 95 variants [IEEE802154] exhibit a frame size of 127 octets, whereas 96 IPv6 requires its underlying layer to support an MTU of 1280 bytes. 97 Furthermore, those IEEE Std 802.15.4 variants do not offer 98 fragmentation and reassembly functionality. (It is noted that IEEE 99 Std 802.15.9-2016 provides multiplexing and fragmentation layer for 100 the IEEE Std 802.15.4[IEEE802159].) Therefore, an appropriate 101 adaptation layer supporting fragmentation and reassembly must be 102 provided below IPv6. Also, the limited IEEE Std 802.15.4 frame size 103 and low energy consumption requirements motivate the need for packet 104 header compression. The IETF IPv6 over Low-Power WPAN (6LoWPAN) 105 working group published a suite of specification that provide an 106 adaptation layer to support IPv6 over IEEE Std 802.15.4 comprising 107 the following functionality: 109 o Fragmentation and reassembly, address autoconfiguration, and a 110 frame format [RFC4944], 112 o IPv6 (and UDP) header compression [RFC6282], 114 o Neighbor Discovery Optimization for 6LoWPAN [RFC6775][RFC8505]. 116 As Internet of Things (IoT) services become more popular, the IETF 117 6lo working group [IETF_6lo] has defined adaptation layer 118 functionality to support IPv6 over various link layer technologies 119 other than IEEE Std 802.15.4, such as Bluetooth Low Energy (Bluetooth 120 LE), ITU-T G.9959 (Z-Wave), Digital Enhanced Cordless 121 Telecommunications - Ultra Low Energy (DECT-ULE), Master-Slave/Token 122 Passing (MS/TP), Near Field Communication (NFC), and Power Line 123 Communication (PLC). The 6lo adaptation layers use a variation of 124 the 6LoWPAN stack applied to each particular link layer technology. 126 The 6LoWPAN working group produced the document entitled "Design and 127 Application Spaces for 6LoWPANs" [RFC6568], which describes potential 128 application scenarios and use cases for low-power wireless personal 129 area networks. The present document aims to provide guidance to an 130 audience who are new to the IPv6 over constrained node networks (6lo) 131 concept and want to assess its application to the constrained node 132 network of their interest. This 6lo applicability document describes 133 a few sets of practical 6lo deployment scenarios and use cases 134 examples. In addition, it considers various network design space 135 dimensions such as deployment, network size, power source, 136 connectivity, multi-hop communication, traffic pattern, security 137 level, mobility, and QoS requirements etc. 139 This document provides the applicability and use cases of 6lo, 140 considering the following aspects: 142 o It covers various IoT-related wired/wireless link layer 143 technologies providing practical information of such technologies. 145 o It provides a general guideline on how the 6LoWPAN stack can be 146 modified for a given L2 technology. 148 o Various 6lo use cases and practical deployment examples are 149 described. 151 2. 6lo Link layer technologies 153 2.1. ITU-T G.9959 155 The ITU-T G.9959 Recommendation [G.9959] targets low-power Wireless 156 Personal Area Networks (WPANs), and defines physical layer and link 157 layer functionality. Physical layers of 9.6 kbit/s, 40 kbit/s and 158 100 kbit/s are supported. G.9959 defines how a unique 32-bit HomeID 159 network identifier is assigned by a network controller and how an 160 8-bit NodeID host identifier is allocated to each node. NodeIDs are 161 unique within the network identified by the HomeID. The G.9959 162 HomeID represents an IPv6 subnet that is identified by one or more 163 IPv6 prefixes [RFC7428]. The ITU-T G.9959 can be used for smart home 164 applications. 166 2.2. Bluetooth LE 168 Bluetooth LE was introduced in Bluetooth 4.0, enhanced in Bluetooth 169 4.1, and developed further in successive versions. Bluetooth SIG has 170 also published the Internet Protocol Support Profile (IPSP). The 171 IPSP enables discovery of IP-enabled devices and establishment of 172 link-layer connection for transporting IPv6 packets. IPv6 over 173 Bluetooth LE is dependent on both Bluetooth 4.1 and IPSP 1.0 or 174 newer. 176 Many devices such as mobile phones, notebooks, tablets and other 177 handheld computing devices which support Bluetooth 4.0 or subsequent 178 versions also support the low-energy variant of Bluetooth. Bluetooth 179 LE is also being included in many different types of accessories that 180 collaborate with mobile devices. An example of a use case for a 181 Bluetooth LE accessory is a heart rate monitor that sends data via 182 the mobile phone to a server on the Internet [RFC7668]. A typical 183 usage of Bluetooth LE is smartphone-based interaction with 184 constrained devices. Bluetooth LE was originally designed to enable 185 star topology networks. However, recent Bluetooth versions support 186 the formation of extended topologies, and IPv6 support for mesh 187 networks of Bluetooth LE devices is being developed 188 [I-D.ietf-6lo-blemesh] 190 2.3. DECT-ULE 192 DECT-ULE is a low power air interface technology that is designed to 193 support both circuit switched services, such as voice communication, 194 and packet mode data services at modest data rate. 196 The DECT-ULE protocol stack consists of the physical layer operating 197 at frequencies in the dedicated 1880 - 1920 MHz frequency band 198 depending on the region and uses a symbol rate of 1.152 Mbps. Radio 199 bearers are allocated by use of FDMA/TDMA/TDD techniques. 201 In its generic network topology, DECT is defined as a cellular 202 network technology. However, the most common configuration is a star 203 network with a single Fixed Part (FP) defining the network with a 204 number of Portable Parts (PP) attached. The Medium Access Control 205 (MAC) layer supports traditional DECT as this is used for services 206 like discovery, pairing, security features etc. All these features 207 have been reused from DECT. 209 The DECT-ULE device can switch to the ULE mode of operation, 210 utilizing the new ULE MAC layer features. The DECT-ULE Data Link 211 Control (DLC) provides multiplexing as well as segmentation and re- 212 assembly for larger packets from layers above. The DECT-ULE layer 213 also implements per-message authentication and encryption. The DLC 214 layer ensures packet integrity and preserves packet order, but 215 delivery is based on best effort. 217 The current DECT-ULE MAC layer standard supports low bandwidth data 218 broadcast. However the usage of this broadcast service has not yet 219 been standardized for higher layers [RFC8105]. DECT-ULE can be used 220 for smart metering in a home. 222 2.4. MS/TP 224 MS/TP is a MAC protocol for the RS-485 [TIA-485-A] physical layer and 225 is used primarily in building automation networks. 227 An MS/TP device is typically based on a low-cost microcontroller with 228 limited processing power and memory. These constraints, together 229 with low data rates and a small MAC address space, are similar to 230 those faced in 6LoWPAN networks. MS/TP differs significantly from 231 6LoWPAN in at least three respects: a) MS/TP devices are typically 232 mains powered, b) all MS/TP devices on a segment can communicate 233 directly so there are no hidden node or mesh routing issues, and c) 234 the latest MS/TP specification provides support for large payloads, 235 eliminating the need for fragmentation and reassembly below IPv6. 237 MS/TP is designed to enable multidrop networks over shielded twisted 238 pair wiring. It can support network segments up to 1000 meters in 239 length at a data rate of 115.2 kbit/s or segments up to 1200 meters 240 in length at lower bit rates. An MS/TP interface requires only a 241 Universal Asynchronous Receiver-Transmitter (UART), an RS-485 242 [TIA-485-A] transceiver with a driver that can be disabled, and a 5 243 ms resolution timer. The MS/TP MAC is typically implemented in 244 software. 246 Because of its superior "range" (~1 km) compared to many low power 247 wireless data links, MS/TP may be suitable to connect remote devices 248 (such as district heating controllers) to the nearest building 249 control infrastructure over a single link [RFC8163]. 251 2.5. NFC 253 NFC technology enables simple and safe two-way interactions between 254 electronic devices, allowing consumers to perform contactless 255 transactions, access digital content, and connect electronic devices 256 with a single touch. NFC complements many popular consumer level 257 wireless technologies, by utilizing the key elements in existing 258 standards for contactless card technology (ISO/IEC 14443 A&B and 259 JIS-X 6319-4). 261 Extending the capability of contactless card technology, NFC also 262 enables devices to share information at a distance that is less than 263 10 cm with a maximum communication speed of 424 kbps. Users can 264 share business cards, make transactions, access information from a 265 smart poster or provide credentials for access control systems with a 266 simple touch. 268 NFC's bidirectional communication ability is ideal for establishing 269 connections with other technologies by the simplicity of touch. In 270 addition to the easy connection and quick transactions, simple data 271 sharing is also available [I-D.ietf-6lo-nfc]. NFC can be used for 272 secure transfer in healthcare services. 274 2.6. PLC 276 PLC is a data transmission technique that utilizes power conductors 277 as medium [I-D.ietf-6lo-plc]. Unlike other dedicated communication 278 infrastructure, power conductors are widely available indoors and 279 outdoors. Moreover, wired technologies cause less interference to 280 the radio medium than wireless technologies and are more reliable 281 than their wireless counterparts. 283 The below table shows some available open standards defining PLC. 285 +-------------+-----------------+------------+-----------+----------+ 286 | PLC Systems | Frequency Range | Type | Data Rate | Distance | 287 +-------------+-----------------+------------+-----------+----------+ 288 | IEEE1901 | <100MHz | Broadband | 200Mbps | 1000m | 289 | | | | | | 290 | IEEE1901.1 | <12MHz | PLC-IoT | 10Mbps | 2000m | 291 | | | | | | 292 | IEEE1901.2 | <500kHz | Narrowband | 200kbps | 3000m | 293 | | | | | | 294 | G3-PLC | <500kHz | Narrowband | 234kbps | 3000m | 295 +-------------+-----------------+------------+-----------+----------+ 297 Table 1: Some Available Open Standards in PLC 299 IEEE Std 1901 [IEEE1901] defines a broadband variant of PLC but is 300 effective within short range. This standard addresses the 301 requirements of applications with high data rate such as: Internet, 302 HDTV, Audio, Gaming etc. Broadband operates on Orthogonal Frequency 303 Division Multiplexing (OFDM) modulation. 305 IEEE Std 1901.1 [IEEE1901.1] defines a medium frequency band (less 306 than 12 MHz) broadband PLC technology for smart grid applications 307 based on OFDM. By achieving an extended communication range with 308 medium speeds, this standard can be applied both in indoor and 309 outdoor scenarios, such as Advanced Metering Infrastructure (AMI), 310 street lighting, electric vehicle charging, smart city etc. 312 IEEE Std 1901.2 [IEEE1901.2] defines a narrowband variant of PLC with 313 less data rate but significantly higher transmission range that could 314 be used in an indoor or even an outdoor environment. It is 315 applicable to typical IoT applications such as: Building Automation, 316 Renewable Energy, Advanced Metering, Street Lighting, Electric 317 Vehicle, Smart Grid etc. Moreover, IEEE Std 1901.2 standard is based 318 on the 802.15.4 MAC sub-layer and fully endorses the security scheme 319 defined in 802.15.4 [RFC8036]. A typical use case of PLC is smart 320 grid. 322 G3-PLC [G3-PLC] is a narrowband PLC technology that is based on the 323 ITU-T G.9903 Recommendation [G.9903]. The ITU-T G.9903 324 Recommendation contains the physical layer and data link layer 325 specification for the G3-PLC narrowband OFDM power line communication 326 transceivers, for communications via alternating current and direct 327 current electric power lines over frequencies below 500 kHz. 329 2.7. Comparison between 6lo link layer technologies 331 In above clauses, various 6lo link layer technologies are described. 332 The following table shows dominant parameters of each use case 333 corresponding to the 6lo link layer technology. 335 +--------------+---------+---------+---------+---------+---------+---------+ 336 | | Z-Wave | BLE | DECT-ULE| MS/TP | NFC | PLC | 337 +--------------+---------+---------+---------+---------+---------+---------+ 338 | | Home | Interact| | Building| Health- | | 339 | Usage | Auto- | w/ Smart| Meter | Auto- | care | Smart | 340 | | mation | Phone | Reading | mation | Service | Grid | 341 +--------------+---------+---------+---------+---------+---------+---------+ 342 | Topology | L2-mesh | Star | Star | MS/TP | P2P | Star | 343 | & | or | & | | | | Tree | 344 | Subnet | L3-mesh | Mesh | No mesh | No mesh | L2-mesh | Mesh | 345 +--------------+---------+---------+---------+---------+---------+---------+ 346 | | | | | | | | 347 | Mobility | No | Low | No | No | Moderate| No | 348 | Requirement | | | | | | | 349 +--------------+---------+---------+---------+---------+---------+---------+ 350 | | High + | | High + | High + | | High + | 351 | Security | Privacy |Partially| Privacy | Authen. | High | Encrypt.| 352 | Requirement | required| | required| required| | required| 353 +--------------+---------+---------+---------+---------+---------+---------+ 354 | | | | | | | | 355 | Buffering | Low | Low | Low | Low | Low | Low | 356 | Requirement | | | | | | | 357 +--------------+---------+---------+---------+---------+---------+---------+ 358 | Latency, | | | | | | | 359 | QoS | High | Low | Low | High | High | Low | 360 | Requirement | | | | | | | 361 +--------------+---------+---------+---------+---------+---------+---------+ 362 | | | | | | | | 363 | Data | Infrequ-| Infrequ-| Infrequ-| Frequent| Small | Infrequ-| 364 | Rate | ent | ent | ent | | | ent | 365 +--------------+---------+---------+---------+---------+---------+---------+ 366 | RFC # | | RFC7668,| | | draft- | draft- | 367 | or | RFC7428 | ietf-6lo| RFC8105 | RFC8163 | ietf-6lo| ietf-6lo| 368 | Draft | | -blemesh| | | -nfc | -plc | 369 +--------------+---------+---------+---------+---------+---------+---------+ 371 Table 2: Comparison between 6lo link layer technologies 373 3. Guidelines for adopting IPv6 stack (6lo) 375 6lo aims at reusing and/or adapting existing 6LoWPAN functionality in 376 order to efficiently support IPv6 over a variety of IoT L2 377 technologies. The following guideline targets new candidate 378 constrained L2 technologies that may be considered for running a 379 modified 6LoWPAN stack on top. The modification of 6LoWPAN stack 380 should be based on the following: 382 o Addressing Model: Addressing model determines whether the device 383 is capable of forming IPv6 link-local and global addresses and 384 what is the best way to derive the IPv6 addresses for the 385 constrained L2 devices. L2-address-derived IPv6 addresses are 386 specified in [RFC4944], but there exist implications for privacy. 387 For global usage, a unique IPv6 address must be derived using an 388 assigned prefix and a unique interface ID. [RFC8065] provides 389 such guidelines. For MAC-derived IPv6 addresses, please refer to 390 [RFC8163] for IPv6 address mapping examples. Broadcast and 391 multicast support are dependent on the L2 networks. Most low- 392 power L2 implementations map multicast to broadcast networks. So 393 care must be taken in the design when to use broadcast and try to 394 stick to unicast messaging whenever possible. 396 o MTU Considerations: The deployment should consider packet maximum 397 transmission unit (MTU) needs over the link layer and should 398 consider if fragmentation and reassembly of packets are needed at 399 the 6LoWPAN layer. For example, if the link layer supports 400 fragmentation and reassembly of packets, then the 6LoWPAN layer 401 may not need to support fragmentation/reassembly. In fact, for 402 most efficiency, choosing a low-power link layer that can carry 403 unfragmented application packets would be optimum for packet 404 transmission if the deployment can afford it. Please refer to 6lo 405 RFCs [RFC7668], [RFC8163], [RFC8105] for example guidance. 407 o Mesh or L3-Routing: 6LoWPAN specifications provide mechanisms to 408 support mesh routing at L2, a configuration called mesh-under 409 [RFC6606]. It is also possible to use an L3 routing protocol in 410 6LoWPAN, an approach known as route-over. [RFC6550] defines RPL, 411 a L3 routing protocol for low power and lossy networks using 412 directed acyclic graphs. 6LoWPAN is routing-protocol-agnostic and 413 does not specify any particular L2 or L3 routing protocol to use 414 with a 6LoWPAN stack. 416 o Address Assignment: 6LoWPAN developed a new version of IPv6 417 Neighbor Discovery [RFC4861][RFC4862]. 6LoWPAN Neighbor Discovery 418 [RFC6775][RFC8505] inherits from IPv6 Neighbor Discovery for 419 mechanisms such as Stateless Address Autoconfiguration (SLAAC) and 420 Neighbor Unreachability Detection (NUD). A 6LoWPAN node is also 421 expected to be an IPv6 host per [RFC8200] which means it should 422 ignore consumed routing headers and Hop-by-Hop options; when 423 operating in a RPL network [RFC6550], it is also beneficial to 424 support IP-in-IP encapsulation [RFC9008]. The 6LoWPAN node should 425 also support [RFC8505] and use it as the default Neighbor 426 Discovery method. It is the responsibility of the deployment to 427 ensure unique global IPv6 addresses for Internet connectivity. 428 For local-only connectivity IPv6 Unique Local Address (ULA) may be 429 used. [RFC6775][RFC8505] specifies the 6LoWPAN border router 430 (6LBR), which is responsible for prefix assignment to the 6LoWPAN 431 network. A 6LBR can be connected to the Internet or to an 432 enterprise network via one of the interfaces. Please refer to 433 [RFC7668] and [RFC8105] for examples of address assignment 434 considerations. In addition, privacy considerations [RFC8065] 435 must be consulted for applicability. In certain scenarios, the 436 deployment may not support IPv6 address autoconfiguration due to 437 regulatory and business reasons and may choose to offer a separate 438 address assignment service. Address Protection for 6LoWPAN 439 Neighbor Discovery (AP-ND) [RFC8928] enables Source Address 440 Validation [RFC6620] and protects the address ownership against 441 impersonation attacks. 443 o Broadcast Avoidance: 6LoWPAN Neighbor Discovery aims at reducing 444 the amount of multicast traffic of classical Neighbor Discovery, 445 since IP-level multicast translates into L2 broadcast in many L2 446 technologies. 6LoWPAN Neighbor Discovery relies on a proactive 447 registration to avoid the use of multicast for address resolution. 448 It also uses a unicast method for Duplicate Address Detection 449 (DAD), and avoids multicast lookups from all nodes by using non- 450 onlink prefixes. Router Advertisements (RAs) are also sent in 451 unicast, in response to Router Solicitations (RSs) 453 o Host-to-Router interface: 6lo has defined registration extensions 454 for 6LoWPAN Neighbor Discovery [RFC8505]. This effort provides a 455 host-to-router interface by which a host can request its router to 456 ensure reachability for the address registered with the router. 457 Note that functionality has been developed to ensure that such a 458 host can benefit from routing services in a RPL network [RFC9010] 460 o Proxy Neighbor Discovery: Further functionality also allows a 461 device (e.g. an energy-constrained device that needs to sleep most 462 of the time) to request proxy Neighbor Discovery services from a 463 6LoWPAN Backbone Router (6BBR) [RFC8505][RFC8929]. The latter 464 federates a number of links into a multilink subnet. 466 o Header Compression: IPv6 header compression [RFC6282] is a vital 467 part of IPv6 over low power communication. Examples of header 468 compression over different link-layer specifications are found in 470 [RFC7668], [RFC8163], [RFC8105]. A generic header compression 471 technique is specified in [RFC7400]. For 6LoWPAN networks where 472 RPL is the routing protocol, there exist 6LoWPAN header 473 compression extensions which allow to compress also the RPL 474 artifacts used when forwarding packets in the route-over mesh 475 [RFC8138] [RFC9035] 477 o Security and Encryption: Though 6LoWPAN basic specifications do 478 not address security at the network layer, the assumption is that 479 L2 security must be present. In addition, application-level 480 security is highly desirable. The working groups [IETF_ace] and 481 [IETF_core] should be consulted for application and transport 482 level security. 6lo working group is working on address 483 authentication [RFC8928] and secure bootstrapping is also being 484 discussed at IETF. However, there may be different levels of 485 security available in a deployment through other standards such as 486 hardware-level security or certificates for initial booting 487 process. Encryption is important if the implementation can afford 488 it. 490 o Additional processing: [RFC8066] defines guidelines for ESC 491 dispatch octets use in the 6LoWPAN header. An implementation may 492 take advantage of ESC header to offer a deployment specific 493 processing of 6LoWPAN packets. 495 4. 6lo Deployment Scenarios 497 4.1. Wi-SUN usage of 6lo in network layer 499 Wireless Smart Ubiquitous Network (Wi-SUN)[Wi-SUN] is a technology 500 based on the IEEE Std 802.15.4g standard. Wi-SUN networks support 501 star and mesh topologies, as well as hybrid star/mesh deployments, 502 but these are typically laid out in a mesh topology where each node 503 relays data for the network to provide network connectivity. Wi-SUN 504 networks are deployed on both powered and battery-operated devices 505 [RFC8376]. 507 The main application domains targeted by Wi-SUN are smart utility and 508 smart city networks. This includes, but is not limited to the 509 following applications: 511 o Advanced Metering Infrastructure 513 o Distribution Automation 515 o Home Energy Management 517 o Infrastructure Management 518 o Intelligent Transportation Systems 520 o Smart Street Lighting 522 o Agriculture 524 o Structural health (bridges, buildings) 526 o Monitoring and Asset Management 528 o Smart Thermostats, Air Conditioning and Heat Controls 530 o Energy Usage Information Displays 532 The Wi-SUN Alliance Field Area Network (FAN) covers primarily outdoor 533 networks, and its specification is oriented towards meeting the more 534 rigorous challenges of these environments. It has the following 535 features: 537 o Open standards based on IEEE802, IETF, TIA, ETSI 539 o Architecture based on an IPv6 frequency hopping wireless mesh 540 network with enterprise-level security 542 o Simple infrastructure of low cost, low complexity 544 o Enhanced network robustness, reliability, and resilience to 545 interference, due to high redundancy and frequency hopping 547 o Enhanced scalability, long range, and energy friendliness 549 o Supports multiple global license-exempt sub-GHz bands 551 o Multi-vendor interoperability 553 o Very low power modes in development permitting long term battery 554 operation of network nodes 556 The Wi-SUN FAN specification defines an IPv6-based protocol suite 557 including TCP/UDP, IPv6, 6lo adaptation layer, DHCPv6 for IPv6 558 address management, RPL, and ICMPv6. 560 4.2. Thread usage of 6lo in network layer 562 Thread is an IPv6-based networking protocol stack built on open 563 standards, designed for smart home environments, and based on low- 564 power IEEE Std 802.15.4 mesh networks. Because of its IPv6 565 foundation, Thread can support existing popular application layers 566 and IoT platforms, provide end-to-end security, ease development and 567 enable flexible and future-proof designs [Thread]. 569 The Thread specification uses the IEEE Std 802.15.4 [IEEE802154] 570 physical and MAC layers operating at 250 kbps in the 2.4 GHz band. 572 Thread devices use 6LoWPAN, as defined in [RFC4944][RFC6282], for 573 transmission of IPv6 Packets over IEEE Std 802.15.4 networks. Header 574 compression is used within the Thread network and devices 575 transmitting messages compress the IPv6 header to minimize the size 576 of the transmitted packet. The mesh header is supported for link- 577 layer (i.e., mesh under) forwarding. The mesh header as used in 578 Thread also allows efficient end-to-end fragmentation of messages 579 rather than the hop-by-hop fragmentation specified in [RFC4944]. 580 Mesh under routing in Thread is based on a distance vector protocol 581 in a full mesh topology. 583 4.3. G3-PLC usage of 6lo in network layer 585 G3-PLC [G3-PLC] is a narrowband PLC technology that is based on the 586 ITU-T G.9903 Recommendation [G.9903]. G3-PLC supports multi-hop mesh 587 network topology, and facilitates highly-reliable, long-range 588 communication. With the abilities to support IPv6 and to cross 589 transformers, G3-PLC is regarded as one of the next-generation 590 narrowband PLC technologies. G3-PLC has got massive deployments over 591 several countries, e.g. Japan and France. 593 The main application domains targeted by G3-PLC are smart grid and 594 smart cities. This includes, but is not limited to the following 595 applications: 597 o Smart Metering 599 o Vehicle-to-Grid Communication 601 o Demand Response 603 o Distribution Automation 605 o Home/Building Energy Management Systems 607 o Smart Street Lighting 609 o Advanced Metering Infrastructure (AMI) backbone network 611 o Wind/Solar Farm Monitoring 612 In the G3-PLC specification, the 6lo adaption layer utilizes the 613 6LoWPAN functions (e.g. header compression, fragmentation and 614 reassembly). However, due to the different characteristics of the 615 PLC media, the 6LoWPAN adaptation layer cannot perfectly fulfill the 616 requirements [I-D.ietf-6lo-plc]. The ESC dispatch type is used in 617 the G3-PLC to provide native mesh routing and bootstrapping 618 functionalities [RFC8066]. 620 4.4. Netricity usage of 6lo in network layer 622 The Netricity program in HomePlug Powerline Alliance [NETRICITY] 623 promotes the adoption of products built on the IEEE Std 1901.2 low- 624 frequency narrowband PLC standard, which provides for urban and long 625 distance communications and propagation through transformers of the 626 distribution network using frequencies below 500 kHz. The technology 627 also addresses requirements that assure communication privacy and 628 secure networks. 630 The main application domains targeted by Netricity are smart grid and 631 smart cities. This includes, but is not limited to the following 632 applications: 634 o Utility grid modernization 636 o Distribution automation 638 o Meter-to-Grid connectivity 640 o Micro-grids 642 o Grid sensor communications 644 o Load control 646 o Demand response 648 o Net metering 650 o Street Lighting control 652 o Photovoltaic panel monitoring 654 Netricity system architecture is based on the physical and MAC layers 655 of IEEE Std 1901.2 PLC standard. Regarding the 6lo adaptation layer 656 and IPv6 network layer, Netricity utilizes IPv6 protocol suite 657 including 6lo/6LoWPAN header compression, DHCPv6 for IP address 658 management, RPL routing protocol, ICMPv6, and unicast/multicast 659 forwarding. Note that the L3 routing in Netricity uses RPL in non- 660 storing mode with the MRHOF objective function based on the own 661 defined Estimated Transmission Time (ETT) metric. 663 5. 6lo Use Case Examples 665 As IPv6 stacks for constrained node networks use a variation of the 666 6LoWPAN stack applied to each particular link layer technology, 667 various 6lo use cases can be provided. In this section, various 6lo 668 use cases which are based on different link layer technologies are 669 described. 671 5.1. Use case of ITU-T G.9959: Smart Home 673 Z-Wave is one of the main technologies that may be used to enable 674 smart home applications. Born as a proprietary technology, Z-Wave 675 was specifically designed for this particular use case. Recently, 676 the Z-Wave radio interface (physical and MAC layers) has been 677 standardized as the ITU-T G.9959 specification. 679 Example: Use of ITU-T G.9959 for Home Automation 681 Variety of home devices (e.g. light dimmers/switches, plugs, 682 thermostats, blinds/curtains and remote controls) are augmented with 683 ITU-T G.9959 interfaces. A user may turn on/off or may control home 684 appliances by pressing a wall switch or by pressing a button in a 685 remote control. Scenes may be programmed, so that after a given 686 event, the home devices adopt a specific configuration. Sensors may 687 also periodically send measurements of several parameters (e.g. gas 688 presence, light, temperature, humidity, etc.) which are collected at 689 a sink device, or may generate commands for actuators (e.g. a smoke 690 sensor may send an alarm message to a safety system). 692 The devices involved in the described scenario are nodes of a network 693 that follows the mesh topology, which is suitable for path diversity 694 to face indoor multipath propagation issues. The multihop paradigm 695 allows end-to-end connectivity when direct range communication is not 696 possible. Security support is required, specially for safety-related 697 communication. When a user interaction (e.g. a button press) 698 triggers a message that encapsulates a command, if the message is 699 lost, the user may have to perform further interactions to achieve 700 the desired effect (e.g. turning off a light). A reaction to a user 701 interaction will be perceived by the user as immediate as long as the 702 reaction takes place within 0.5 seconds [RFC5826]. 704 5.2. Use case of Bluetooth LE: Smartphone-based Interaction 706 The key feature behind the current high Bluetooth LE momentum is its 707 support in a large majority of smartphones in the market. Bluetooth 708 LE can be used to allow the interaction between the smartphone and 709 surrounding sensors or actuators. Furthermore, Bluetooth LE is also 710 the main radio interface currently available in wearables. Since a 711 smartphone typically has several radio interfaces that provide 712 Internet access, such as Wi-Fi or 4G, the smartphone can act as a 713 gateway for nearby devices such as sensors, actuators or wearables. 714 Bluetooth LE may be used in several domains, including healthcare, 715 sports/wellness and home automation. 717 Example: Use of Bluetooth LE-based Body Area Network for fitness 719 A person wears a smartwatch for fitness purposes. The smartwatch has 720 several sensors (e.g. heart rate, accelerometer, gyrometer, GPS, 721 temperature, etc.), a display, and a Bluetooth LE radio interface. 722 The smartwatch can show fitness-related statistics on its display. 723 However, when a paired smartphone is in the range of the smartwatch, 724 the latter can report almost real-time measurements of its sensors to 725 the smartphone, which can forward the data to a cloud service on the 726 Internet. 6lo enables this use case by providing efficient end-to-end 727 IPv6 support. In addition, the smartwatch can receive notifications 728 (e.g. alarm signals) from the cloud service via the smartphone. On 729 the other hand, the smartphone may locally generate messages for the 730 smartwatch, such as e-mail reception or calendar notifications. 732 The functionality supported by the smartwatch may be complemented by 733 other devices such as other on-body sensors, wireless headsets or 734 head-mounted displays. All such devices may connect to the 735 smartphone creating a star topology network whereby the smartphone is 736 the central component. Support for extended network topologies (e.g. 737 mesh networks) is being developed as of the writing. 739 5.3. Use case of DECT-ULE: Smart Home 741 DECT is a technology widely used for wireless telephone 742 communications in residential scenarios. Since DECT-ULE is a low- 743 power variant of DECT, DECT-ULE can be used to connect constrained 744 devices such as sensors and actuators to a Fixed Part, a device that 745 typically acts as a base station for wireless telephones. Therefore, 746 DECT-ULE is specially suitable for the connected home space in 747 application areas such as home automation, smart metering, safety, 748 healthcare, etc. Since DECT-ULE uses dedicated bandwidth, it avoids 749 the coexistence issues suffered by other technologies that use e.g. 750 ISM frequency bands. 752 Example: Use of DECT-ULE for Smart Metering 754 The smart electricity meter of a home is equipped with a DECT-ULE 755 transceiver. This device is in the coverage range of the Fixed Part 756 of the home. The Fixed Part can act as a router connected to the 757 Internet. This way, the smart meter can transmit electricity 758 consumption readings through the DECT-ULE link with the Fixed Part, 759 and the latter can forward such readings to the utility company using 760 Wide Area Network (WAN) links. The meter can also receive queries 761 from the utility company or from an advanced energy control system 762 controlled by the user, which may also be connected to the Fixed Part 763 via DECT-ULE. 765 5.4. Use case of MS/TP: Building Automation Networks 767 The primary use case for IPv6 over MS/TP (6LoBAC) is in building 768 automation networks. [BACnet] is the open international standard 769 protocol for building automation, and MS/TP is defined in [BACnet] 770 Clause 9. MS/TP was designed to be a low cost multi-drop field bus 771 to inter-connect the most numerous elements (sensors and actuators) 772 of a building automation network to their controllers. A key aspect 773 of 6LoBAC is that it is designed to co-exist with BACnet MS/TP on the 774 same link, easing the ultimate transition of some BACnet networks to 775 native end-to-end IPv6 transport protocols. New applications for 776 6LoBAC may be found in other domains where low cost, long distance, 777 and low latency are required. Note that BACnet comprises various 778 networking solutions other than MS/TP, including the recently emerged 779 BACnet IP. However, the latter is based on high speed Ethernet 780 infrastructure, and thus it falls outside of the constrained node 781 network scope. 783 Example: Use of 6LoBAC in Building Automation Networks 785 The majority of installations for MS/TP are for "terminal" or 786 "unitary" controllers, i.e. single zone or room controllers that may 787 connect to HVAC or other controls such as lighting or blinds. The 788 economics of daisy-chaining a single twisted-pair between multiple 789 devices is often preferred over home-run Cat-5 style wiring. 791 A multi-zone controller might be implemented as an IP router between 792 a traditional Ethernet link and several 6LoBAC links, fanning out to 793 multiple terminal controllers. 795 The superior distance capabilities of MS/TP (~1 km) compared to other 796 6lo media may suggest its use in applications to connect remote 797 devices to the nearest building infrastructure. For example, remote 798 pumping or measuring stations with moderate bandwidth requirements 799 can benefit from the low cost and robust capabilities of MS/TP over 800 other wired technologies such as DSL, and without the line-of-sight 801 restrictions or hop-by-hop latency of many low cost wireless 802 solutions. 804 5.5. Use case of NFC: Alternative Secure Transfer 806 In different applications, a variety of secured data can be handled 807 and transferred. Depending on the security level of the data, 808 different transfer methods can be alternatively selected. 810 Example: Use of NFC for Secure Transfer in Healthcare Services with 811 Tele-Assistance 813 A senior citizen who lives alone wears one to several wearable 6lo 814 devices to measure heartbeat, pulse rate, etc. The 6lo devices are 815 densely installed at home for movement detection. A 6LBR at home 816 will send the sensed information to a connected healthcare center. 817 Portable base stations with LCDs may be used to check the data at 818 home, as well. Data is gathered in both periodic and event-driven 819 fashion. In this application, event-driven data can be very time- 820 critical. In addition, privacy also becomes a serious issue in this 821 case, as the sensed data is very personal. 823 While the senior citizen is provided audio and video healthcare 824 services by a tele-assistance based on LTE connections, the senior 825 citizen can alternatively use NFC connections to transfer the 826 personal sensed data to the tele-assistance. Hidden hackers can 827 overhear the data based on the LTE connection, but they cannot gather 828 the personal data over the NFC connection. 830 5.6. Use case of PLC: Smart Grid 832 The smart grid concept is based on deploying numerous operational and 833 energy measuring sub-systems in an electricity grid system. It 834 comprises multiple administrative levels/segments to provide 835 connectivity among these numerous components. Last mile connectivity 836 is established over the Low Voltage (LV) segment, whereas 837 connectivity over electricity distribution takes place in the High 838 Voltage (HV) segment. Smart grid systems include Advanced Metering 839 Infrastructure (AMI), Demand Response (DR), Home Energy Management 840 System (HEMS), Wide Area Situational Awareness (WASA), among others. 842 Although other wired and wireless technologies are also used in Smart 843 Grid, PLC enjoys the advantage of reliable data communication over 844 electrical power lines that are already present, and the deployment 845 cost can be comparable to wireless technologies. The 6lo-related 846 scenarios for PLC mainly lie in the LV PLC networks with most 847 applications in the area of Advanced Metering Infrastructure, 848 Vehicle-to-Grid communications, in-home energy management and smart 849 street lighting. 851 Example: Use of PLC for Advanced Metering Infrastructure 853 Household electricity meters transmit time-based data of electric 854 power consumption through PLC. Data concentrators receive all the 855 meter data in their corresponding living districts and send them to 856 the Meter Data Management System (MDMS) through WAN network (e.g. 857 Medium-Voltage PLC, Ethernet or GPRS) for storage and analysis. Two- 858 way communications are enabled which means smart meters can do 859 actions like notification of electricity charges according to the 860 commands from the utility company. 862 With the existing power line infrastructure as communication medium, 863 cost on building up the PLC network is naturally saved, and more 864 importantly, labor operational costs can be minimized from a long- 865 term perspective. Furthermore, this AMI application speeds up 866 electricity charge, reduces losses by restraining power theft and 867 helps to manage the health of the grid based on line loss analysis. 869 Example: Use of PLC (IEEE Std 1901.1) for WASA in Smart Grid 871 Many sub-systems of Smart Grid require low data rate and narrowband 872 variants (e.g., IEEE Std 1901.1) of PLC fulfill such requirements. 873 Recently, more complex scenarios are emerging that require higher 874 data rates. 876 WASA sub-system is an appropriate example that collects large amount 877 of information about the current state of the grid over wide area 878 from electric substations as well as power transmission lines. The 879 collected feedback is used for monitoring, controlling and protecting 880 all the sub-systems. 882 6. IANA Considerations 884 There are no IANA considerations related to this document. 886 7. Security Considerations 888 Security considerations are not directly applicable to this document. 889 For the use cases, the security requirements described in the 890 protocol specifications apply. 892 8. Acknowledgements 894 Carles Gomez has been funded in part by the Spanish Government 895 through the Jose Castillejo CAS15/00336 grant, the TEC2016-79988-P 896 grant, and the PID2019-106808RA-I00 grant, and by Secretaria 897 d'Universitats i Recerca del Departament d'Empresa i Coneixement de 898 la Generalitat de Catalunya 2017 through grant SGR 376. His 899 contribution to this work has been carried out in part during his 900 stay as a visiting scholar at the Computer Laboratory of the 901 University of Cambridge. 903 Thomas Watteyne, Pascal Thubert, Xavier Vilajosana, Daniel Migault, 904 Jianqiang Hou, Kerry Lynn, S.V.R. Anand, and Seyed Mahdi Darroudi 905 have provided valuable feedback for this draft. 907 Das Subir and Michel Veillette have provided valuable information of 908 jupiterMesh and Paul Duffy has provided valuable information of Wi- 909 SUN for this draft. Also, Jianqiang Hou has provided valuable 910 information of G3-PLC and Netricity for this draft. Take Aanstoot, 911 Kerry Lynn, and Dave Robin have provided valuable information of MS/ 912 TP and practical use case of MS/TP for this draft. 914 Deoknyong Ko has provided relevant text of LTE-MTC and he shared his 915 experience to deploy IPv6 and 6lo technologies over LTE MTC in SK 916 Telecom. 918 9. Informative References 920 [BACnet] "ASHRAE, "BACnet-A Data Communication Protocol for 921 Building Automation and Control Networks", ANSI/ASHRAE 922 Standard 135-2016", January 2016, 923 . 926 [G.9903] "International Telecommunication Union, "Narrowband 927 orthogonal frequency division multiplexing power line 928 communication transceivers for G3-PLC networks", ITU-T 929 Recommendation", August 2017. 931 [G.9959] "International Telecommunication Union, "Short range 932 narrow-band digital radiocommunication transceivers - PHY 933 and MAC layer specifications", ITU-T Recommendation", 934 January 2015. 936 [G3-PLC] "G3-PLC Alliance", . 938 [IEEE1901] 939 "IEEE Standard, IEEE Std 1901-2010 - IEEE Standard for 940 Broadband over Power Line Networks: Medium Access Control 941 and Physical Layer Specifications", 2010, 942 . 945 [IEEE1901.1] 946 "IEEE Standard, IEEE Std 1901.1-2018 - IEEE Standard for 947 Medium Frequency (less than 12 MHz) Power Line 948 Communications for Smart Grid Applications", 2018, 949 . 951 [IEEE1901.2] 952 "IEEE Standard, IEEE Std 1901.2-2013 - IEEE Standard for 953 Low-Frequency (less than 500 kHz) Narrowband Power Line 954 Communications for Smart Grid Applications", 2013, 955 . 958 [IEEE802154] 959 IEEE standard for Information Technology, "IEEE Standard 960 for Low-Rate Wireless Networks". 962 [IEEE802159] 963 IEEE standard for Information Technology, "IEEE Std 964 802.15.9-2016 - IEEE Recommended Practice for Transport of 965 Key Management Protocol (KMP) Datagrams". 967 [I-D.ietf-6lo-blemesh] 968 Gomez, C., Darroudi, S., Savolainen, T., and M. Spoerk, 969 "IPv6 Mesh over BLUETOOTH(R) Low Energy using IPSP", 970 draft-ietf-6lo-blemesh-10 (work in progress), April 2021. 972 [I-D.ietf-6lo-nfc] 973 Choi, Y., Hong, Y., Youn, J., Kim, D., and J. Choi, 974 "Transmission of IPv6 Packets over Near Field 975 Communication", draft-ietf-6lo-nfc-17 (work in progress), 976 August 2020. 978 [I-D.ietf-6lo-plc] 979 Hou, J., Liu, B., Hong, Y., Tang, X., and C. Perkins, 980 "Transmission of IPv6 Packets over PLC Networks", draft- 981 ietf-6lo-plc-06 (work in progress), April 2021. 983 [IETF_6lo] 984 "IETF IPv6 over Networks of Resource-constrained Nodes 985 (6lo) working group", 986 . 988 [IETF_ace] 989 "IETF Authentication and Authorization for Constrained 990 Environments (ace) working group", 991 . 993 [IETF_core] 994 "IETF Constrained RESTful Environments (core) working 995 group", . 997 [Wi-SUN] "Wi-SUN Alliance", . 999 [Thread] "Thread Group", . 1001 [NETRICITY] 1002 "Netricity program in HomePlug Powerline Alliance", 1003 . 1005 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 1006 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 1007 DOI 10.17487/RFC4861, September 2007, 1008 . 1010 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 1011 Address Autoconfiguration", RFC 4862, 1012 DOI 10.17487/RFC4862, September 2007, 1013 . 1015 [RFC4919] Kushalnagar, N., Montenegro, G., and C. Schumacher, "IPv6 1016 over Low-Power Wireless Personal Area Networks (6LoWPANs): 1017 Overview, Assumptions, Problem Statement, and Goals", 1018 RFC 4919, DOI 10.17487/RFC4919, August 2007, 1019 . 1021 [RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler, 1022 "Transmission of IPv6 Packets over IEEE 802.15.4 1023 Networks", RFC 4944, DOI 10.17487/RFC4944, September 2007, 1024 . 1026 [RFC5826] Brandt, A., Buron, J., and G. Porcu, "Home Automation 1027 Routing Requirements in Low-Power and Lossy Networks", 1028 RFC 5826, DOI 10.17487/RFC5826, April 2010, 1029 . 1031 [RFC6282] Hui, J., Ed. and P. Thubert, "Compression Format for IPv6 1032 Datagrams over IEEE 802.15.4-Based Networks", RFC 6282, 1033 DOI 10.17487/RFC6282, September 2011, 1034 . 1036 [RFC6550] Winter, T., Ed., Thubert, P., Ed., Brandt, A., Hui, J., 1037 Kelsey, R., Levis, P., Pister, K., Struik, R., Vasseur, 1038 JP., and R. Alexander, "RPL: IPv6 Routing Protocol for 1039 Low-Power and Lossy Networks", RFC 6550, 1040 DOI 10.17487/RFC6550, March 2012, 1041 . 1043 [RFC6568] Kim, E., Kaspar, D., and JP. Vasseur, "Design and 1044 Application Spaces for IPv6 over Low-Power Wireless 1045 Personal Area Networks (6LoWPANs)", RFC 6568, 1046 DOI 10.17487/RFC6568, April 2012, 1047 . 1049 [RFC6606] Kim, E., Kaspar, D., Gomez, C., and C. Bormann, "Problem 1050 Statement and Requirements for IPv6 over Low-Power 1051 Wireless Personal Area Network (6LoWPAN) Routing", 1052 RFC 6606, DOI 10.17487/RFC6606, May 2012, 1053 . 1055 [RFC6620] Nordmark, E., Bagnulo, M., and E. Levy-Abegnoli, "FCFS 1056 SAVI: First-Come, First-Served Source Address Validation 1057 Improvement for Locally Assigned IPv6 Addresses", 1058 RFC 6620, DOI 10.17487/RFC6620, May 2012, 1059 . 1061 [RFC6775] Shelby, Z., Ed., Chakrabarti, S., Nordmark, E., and C. 1062 Bormann, "Neighbor Discovery Optimization for IPv6 over 1063 Low-Power Wireless Personal Area Networks (6LoWPANs)", 1064 RFC 6775, DOI 10.17487/RFC6775, November 2012, 1065 . 1067 [RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for 1068 Constrained-Node Networks", RFC 7228, 1069 DOI 10.17487/RFC7228, May 2014, 1070 . 1072 [RFC7400] Bormann, C., "6LoWPAN-GHC: Generic Header Compression for 1073 IPv6 over Low-Power Wireless Personal Area Networks 1074 (6LoWPANs)", RFC 7400, DOI 10.17487/RFC7400, November 1075 2014, . 1077 [RFC7428] Brandt, A. and J. Buron, "Transmission of IPv6 Packets 1078 over ITU-T G.9959 Networks", RFC 7428, 1079 DOI 10.17487/RFC7428, February 2015, 1080 . 1082 [RFC7668] Nieminen, J., Savolainen, T., Isomaki, M., Patil, B., 1083 Shelby, Z., and C. Gomez, "IPv6 over BLUETOOTH(R) Low 1084 Energy", RFC 7668, DOI 10.17487/RFC7668, October 2015, 1085 . 1087 [RFC8036] Cam-Winget, N., Ed., Hui, J., and D. Popa, "Applicability 1088 Statement for the Routing Protocol for Low-Power and Lossy 1089 Networks (RPL) in Advanced Metering Infrastructure (AMI) 1090 Networks", RFC 8036, DOI 10.17487/RFC8036, January 2017, 1091 . 1093 [RFC8065] Thaler, D., "Privacy Considerations for IPv6 Adaptation- 1094 Layer Mechanisms", RFC 8065, DOI 10.17487/RFC8065, 1095 February 2017, . 1097 [RFC8066] Chakrabarti, S., Montenegro, G., Droms, R., and J. 1098 Woodyatt, "IPv6 over Low-Power Wireless Personal Area 1099 Network (6LoWPAN) ESC Dispatch Code Points and 1100 Guidelines", RFC 8066, DOI 10.17487/RFC8066, February 1101 2017, . 1103 [RFC8105] Mariager, P., Petersen, J., Ed., Shelby, Z., Van de Logt, 1104 M., and D. Barthel, "Transmission of IPv6 Packets over 1105 Digital Enhanced Cordless Telecommunications (DECT) Ultra 1106 Low Energy (ULE)", RFC 8105, DOI 10.17487/RFC8105, May 1107 2017, . 1109 [RFC8138] Thubert, P., Ed., Bormann, C., Toutain, L., and R. Cragie, 1110 "IPv6 over Low-Power Wireless Personal Area Network 1111 (6LoWPAN) Routing Header", RFC 8138, DOI 10.17487/RFC8138, 1112 April 2017, . 1114 [RFC8163] Lynn, K., Ed., Martocci, J., Neilson, C., and S. 1115 Donaldson, "Transmission of IPv6 over Master-Slave/Token- 1116 Passing (MS/TP) Networks", RFC 8163, DOI 10.17487/RFC8163, 1117 May 2017, . 1119 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 1120 (IPv6) Specification", STD 86, RFC 8200, 1121 DOI 10.17487/RFC8200, July 2017, 1122 . 1124 [RFC8352] Gomez, C., Kovatsch, M., Tian, H., and Z. Cao, Ed., 1125 "Energy-Efficient Features of Internet of Things 1126 Protocols", RFC 8352, DOI 10.17487/RFC8352, April 2018, 1127 . 1129 [RFC8376] Farrell, S., Ed., "Low-Power Wide Area Network (LPWAN) 1130 Overview", RFC 8376, DOI 10.17487/RFC8376, May 2018, 1131 . 1133 [RFC8505] Thubert, P., Ed., Nordmark, E., Chakrabarti, S., and C. 1134 Perkins, "Registration Extensions for IPv6 over Low-Power 1135 Wireless Personal Area Network (6LoWPAN) Neighbor 1136 Discovery", RFC 8505, DOI 10.17487/RFC8505, November 2018, 1137 . 1139 [RFC8928] Thubert, P., Ed., Sarikaya, B., Sethi, M., and R. Struik, 1140 "Address-Protected Neighbor Discovery for Low-Power and 1141 Lossy Networks", RFC 8928, DOI 10.17487/RFC8928, November 1142 2020, . 1144 [RFC8929] Thubert, P., Ed., Perkins, C., and E. Levy-Abegnoli, "IPv6 1145 Backbone Router", RFC 8929, DOI 10.17487/RFC8929, November 1146 2020, . 1148 [RFC9008] Robles, M., Richardson, M., and P. Thubert, "Using RPI 1149 Option Type, Routing Header for Source Routes, and IPv6- 1150 in-IPv6 Encapsulation in the RPL Data Plane", RFC 9008, 1151 DOI 10.17487/RFC9008, April 2021, 1152 . 1154 [RFC9010] Thubert, P., Ed. and M. Richardson, "Routing for RPL 1155 (Routing Protocol for Low-Power and Lossy Networks) 1156 Leaves", RFC 9010, DOI 10.17487/RFC9010, April 2021, 1157 . 1159 [RFC9035] Thubert, P., Ed. and L. Zhao, "A Routing Protocol for Low- 1160 Power and Lossy Networks (RPL) Destination-Oriented 1161 Directed Acyclic Graph (DODAG) Configuration Option for 1162 the 6LoWPAN Routing Header", RFC 9035, 1163 DOI 10.17487/RFC9035, April 2021, 1164 . 1166 [TIA-485-A] 1167 "TIA, "Electrical Characteristics of Generators and 1168 Receivers for Use in Balanced Digital Multipoint Systems", 1169 TIA-485-A (Revision of TIA-485)", March 2003, 1170 . 1173 Appendix A. Design Space Dimensions for 6lo Deployment 1175 The [RFC6568] lists the dimensions used to describe the design space 1176 of wireless sensor networks in the context of the 6LoWPAN working 1177 group. The design space is already limited by the unique 1178 characteristics of a LoWPAN (e.g. low power, short range, low bit 1179 rate). In [RFC6568], the following design space dimensions are 1180 described: Deployment, Network size, Power source, Connectivity, 1181 Multi-hop communication, Traffic pattern, Mobility, Quality of 1182 Service (QoS). However, in this document, the following design space 1183 dimensions are considered: 1185 o Deployment/Bootstrapping: 6lo nodes can be connected randomly, or 1186 in an organized manner. The bootstrapping has different 1187 characteristics for each link layer technology. 1189 o Topology: Topology of 6lo networks may inherently follow the 1190 characteristics of each link layer technology. Point-to-point, 1191 star, tree or mesh topologies can be configured, depending on the 1192 link layer technology considered. 1194 o L2-Mesh or L3-Mesh: L2-mesh and L3-mesh may inherently follow the 1195 characteristics of each link layer technology. Some link layer 1196 technologies may support L2-mesh and some may not support. 1198 o Multi-link subnet, single subnet: The selection of multi-link 1199 subnet and single subnet depends on connectivity and the number of 1200 6lo nodes. 1202 o Data rate: Typically, the link layer technologies of 6lo have low 1203 rate of data transmission. But, by adjusting the MTU, it can 1204 deliver higher upper layer data rate. 1206 o Buffering requirements: Some 6lo use case may require more data 1207 rate than the link layer technology support. In this case, a 1208 buffering mechanism to manage the data is required. 1210 o Security and Privacy Requirements: Some 6lo use case can involve 1211 transferring some important and personal data between 6lo nodes. 1212 In this case, high-level security support is required. 1214 o Mobility across 6lo networks and subnets: The movement of 6lo 1215 nodes depends on the 6lo use case. If the 6lo nodes can move or 1216 moved around, a mobility management mechanism is required. 1218 o Time synchronization requirements: The requirement of time 1219 synchronization of the upper layer service is dependent on the 6lo 1220 use case. For some 6lo use case related to health service, the 1221 measured data must be recorded with exact time and must be 1222 transferred with time synchronization. 1224 o Reliability and QoS: Some 6lo use case requires high reliability, 1225 for example real-time service or health-related services. 1227 o Traffic patterns: 6lo use cases may involve various traffic 1228 patterns. For example, some 6lo use case may require short data 1229 length and random transmission. Some 6lo use case may require 1230 continuous data and periodic data transmission. 1232 o Security Bootstrapping: Without the external operations, 6lo nodes 1233 must have the security bootstrapping mechanism. 1235 o Power use strategy: to enable certain use cases, there may be 1236 requirements on the class of energy availability and the strategy 1237 followed for using power for communication [RFC7228]. Each link 1238 layer technology defines a particular power use strategy which may 1239 be tuned [RFC8352]. Readers are expected to be familiar with 1240 [RFC7228] terminology. 1242 o Update firmware requirements: Most 6lo use cases will need a 1243 mechanism for updating firmware. In these cases support for over 1244 the air updates are required, probably in a broadcast mode when 1245 bandwidth is low and the number of identical devices is high. 1247 o Wired vs. Wireless: Plenty of 6lo link layer technologies are 1248 wireless, except MS/TP and PLC. The selection of wired or 1249 wireless link layer technology is mainly dependent on the 1250 requirement of 6lo use cases and the characteristics of wired/ 1251 wireless technologies. For example, some 6lo use cases may 1252 require easy and quick deployment, whereas others may need a 1253 continuous source of power. 1255 Authors' Addresses 1257 Yong-Geun Hong 1258 Daejeon University 1259 62 Daehak-ro, Dong-gu 1260 Daejeon 34520 1261 Korea 1263 Phone: +82 42 280 4841 1264 Email: yonggeun.hong@gmail.com 1265 Carles Gomez 1266 Universitat Politecnica de Catalunya/Fundacio i2cat 1267 C/Esteve Terradas, 7 1268 Castelldefels 08860 1269 Spain 1271 Email: carlesgo@entel.upc.edu 1273 Younghwan Choi 1274 ETRI 1275 218 Gajeongno, Yuseong 1276 Daejeon 34129 1277 Korea 1279 Phone: +82 42 860 1429 1280 Email: yhc@etri.re.kr 1282 Abdur Rashid Sangi 1283 Huaiyin Institute of Technology 1284 No.89 North Beijing Road, Qinghe District 1285 Huaian 223001 1286 P.R. China 1288 Email: sangi_bahrian@yahoo.com 1290 Samita Chakrabarti 1291 San Jose, CA 1292 USA 1294 Email: samitac.ietf@gmail.com