Internet Engineering Task Force (IETF)                         Y-G. HongRequest for Comments: 9453                            Daejeon UniversityCategory: Informational                                         C. GomezISSN: 2070-1721                                                      UPC                                                                 Y. Choi                                                                    ETRI                                                                A. Sangi                                                 Wenzhou-Kean University                                                          S. Chakrabarti                                                                 Verizon                                                          September 2023    Applicability and Use Cases for IPv6 over Networks of Resource-                        constrained Nodes (6lo)Abstract   This document describes the applicability of IPv6 over constrained-   node networks (6lo) and provides practical deployment examples.  In   addition to IEEE Std 802.15.4, various link-layer technologies are   used as examples, such as ITU-T G.9959 (Z-Wave), Bluetooth Low Energy   (Bluetooth LE), Digital Enhanced Cordless Telecommunications - Ultra   Low Energy (DECT-ULE), Master-Slave/Token Passing (MS/TP), Near Field   Communication (NFC), and Power Line Communication (PLC).  This   document targets an audience who would like to understand and   evaluate running end-to-end IPv6 over the constrained-node networks   for local or Internet connectivity.Status of This Memo   This document is not an Internet Standards Track specification; it is   published for informational purposes.   This document is a product of the Internet Engineering Task Force   (IETF).  It represents the consensus of the IETF community.  It has   received public review and has been approved for publication by the   Internet Engineering Steering Group (IESG).  Not all documents   approved by the IESG are candidates for any level of Internet   Standard; see Section 2 of RFC 7841.   Information about the current status of this document, any errata,   and how to provide feedback on it may be obtained at   https://www.rfc-editor.org/info/rfc9453.Copyright Notice   Copyright (c) 2023 IETF Trust and the persons identified as the   document authors.  All rights reserved.   This document is subject to BCP 78 and the IETF Trust's Legal   Provisions Relating to IETF Documents   (https://trustee.ietf.org/license-info) in effect on the date of   publication of this document.  Please review these documents   carefully, as they describe your rights and restrictions with respect   to this document.  Code Components extracted from this document must   include Revised BSD License text as described in Section 4.e of the   Trust Legal Provisions and are provided without warranty as described   in the Revised BSD License.Table of Contents   1.  Introduction   2.  6lo Link-Layer Technologies     2.1.  ITU-T G.9959     2.2.  Bluetooth LE     2.3.  DECT-ULE     2.4.  MS/TP     2.5.  NFC     2.6.  PLC     2.7.  Comparison between 6lo Link-Layer Technologies   3.  Guidelines for Adopting an IPv6 Stack (6lo)   4.  6lo Deployment Examples     4.1.  Wi-SUN Usage of 6lo in Network Layer     4.2.  Thread Usage of 6lo in the Network Layer     4.3.  G3-PLC Usage of 6lo in Network Layer     4.4.  Netricity Usage of 6lo in the Network Layer   5.  6lo Use-Case Examples     5.1.  Use Case of ITU-T G.9959: Smart Home     5.2.  Use Case of Bluetooth LE: Smartphone-Based Interaction     5.3.  Use Case of DECT-ULE: Smart Home     5.4.  Use Case of MS/TP: Building Automation Networks     5.5.  Use Case of NFC: Alternative Secure Transfer     5.6.  Use Case of PLC: Smart Grid   6.  IANA Considerations   7.  Security Considerations   8.  References     8.1.  Normative References     8.2.  Informative References   Appendix A.  Design Space Dimensions for 6lo Deployment   Acknowledgements   Authors' Addresses1.  Introduction   Running IPv6 on constrained-node networks presents challenges due to   the characteristics of these networks, such as small packet size, low   power, low bandwidth, and large number of devices, among others   [RFC4919] [RFC7228].  For example, many IEEE Std 802.15.4 variants   [IEEE-802.15.4] exhibit a frame size of 127 octets, whereas IPv6   requires its underlying layer to support an MTU of 1280 bytes.   Furthermore, those IEEE Std 802.15.4 variants do not offer   fragmentation and reassembly functionality.  (It is noted that IEEE   Std 802.15.9-2021 provides a multiplexing and fragmentation layer for   the IEEE Std 802.15.4 [IEEE-802.15.9].)  Therefore, an appropriate   adaptation layer supporting fragmentation and reassembly must be   provided below IPv6.  Also, the limited IEEE Std 802.15.4 frame size   and low energy consumption requirements motivate the need for packet   header compression.  The IETF IPv6 over Low-Power Wireless Personal   Area Network (6LoWPAN) Working Group published a suite of   specifications that provides an adaptation layer to support IPv6 over   IEEE Std 802.15.4 comprising the following functionalities:   *  fragmentation and reassembly, address autoconfiguration, and a      frame format [RFC4944]   *  IPv6 (and UDP) header compression [RFC6282]   *  Neighbor Discovery Optimization for 6LoWPAN [RFC6775] [RFC8505]   As Internet of Things (IoT) services become more popular, the IETF   has defined adaptation layer functionality to support IPv6 over   various link-layer technologies other than IEEE Std 802.15.4, such as   Bluetooth Low Energy (Bluetooth LE), ITU-T G.9959 (Z-Wave), Digital   Enhanced Cordless Telecommunications - Ultra Low Energy (DECT-ULE),   Master-Slave/Token Passing (MS/TP), Near Field Communication (NFC),   and Power Line Communication (PLC).  The 6lo adaptation layers use a   variation of the 6LoWPAN stack applied to each particular link-layer   technology.   The 6LoWPAN Working Group produced the document entitled "Design and   Application Spaces for IPv6 over Low-Power Wireless Personal Area   Networks (6LoWPANs)" [RFC6568], which describes potential application   scenarios and use cases for LoWPANs.  The present document aims to   provide guidance to an audience that is new to the IPv6 over   constrained-node networks (6lo) concept and want to assess its   application to the constrained-node network of their interest.  This   6lo applicability document describes a few sets of practical 6lo   deployment scenarios and use-case examples.  In addition, it   considers various network design space dimensions, such as   Deployment, Network Size, Power Source, Connectivity, Multi-Hop   Communication, Traffic pattern, Mobility, and QoS requirements (see   Appendix A).   This document provides the applicability and use cases of 6lo,   considering the following aspects:   *  Various IoT-related wired or wireless link-layer technologies      providing practical information about such technologies.   *  General guidelines on how the 6LoWPAN stack can be modified for a      given L2 technology.   *  Various 6lo use cases and practical deployment examples.   Note that the use of "master" and "slave" have been retained in this   document to align with use within the industry (e.g., [TIA-485-A] and   [BACnet]).2.  6lo Link-Layer Technologies2.1.  ITU-T G.9959   The ITU-T G.9959 Recommendation [G.9959] targets LoWPANs and defines   physical-layer and link-layer functionality.  Physical layers of 9.6   kbit/s, 40 kbit/s, and 100 kbit/s are supported.   [G.9959] defines how a unique 32-bit HomeID network identifier is   assigned by a network controller and how an 8-bit NodeID host   identifier is allocated to each node.  NodeIDs are unique within the   network identified by the HomeID.  The G.9959 HomeID represents an   IPv6 subnet that is identified by one or more IPv6 prefixes   [RFC7428].  ITU-T G.9959 can be used for smart home applications, and   the transmission range is 100 meters per hop.2.2.  Bluetooth LE   Bluetooth LE was introduced in Bluetooth 4.0, enhanced in Bluetooth   4.1, and developed further in successive versions.  The data rate of   Bluetooth LE is 125 kb/s, 500 kb/s, 1 Mb/s, 2 Mb/s; and max   transmission range is around 100 meters (outdoors).  The Bluetooth   Special Interest Group (Bluetooth SIG) has also published the   Internet Protocol Support Profile (IPSP).  The IPSP enables discovery   of IP-enabled devices and establishment of link-layer connections for   transporting IPv6 packets.  IPv6 over Bluetooth LE is dependent on   both Bluetooth 4.1 [BTCorev5.4] and IPSP 1.0 [IPSP] or newer.   Many devices such as mobile phones, notebooks, tablets, and other   handheld computing devices that support Bluetooth 4.0 or subsequent   versions also support the low-energy variant of Bluetooth.  Bluetooth   LE is also being included in many different types of accessories that   collaborate with mobile devices.  An example of a use case for a   Bluetooth LE accessory is a heart rate monitor that sends data via   the mobile phone to a server on the Internet [RFC7668].  A typical   usage of Bluetooth LE is smartphone-based interaction with   constrained devices.  Bluetooth LE was originally designed to enable   star topology networks.  However, recent Bluetooth versions support   the formation of extended topologies, and IPv6 support for mesh   networks of Bluetooth LE devices has been developed [RFC9159].2.3.  DECT-ULE   DECT-ULE is a low-power air interface technology that is designed to   support both circuit-switched services, such as voice communication,   and packet-mode data services at modest data rate [TS102.939-1]   [TS102.939-2].   The DECT-ULE protocol stack consists of the physical layer operating   at frequencies in the dedicated 1880 - 1920 MHz frequency band   depending on the region and uses a symbol rate of 1.152 Mbps.  Radio   bearers are allocated by use of Frequency-Division Multiplex (FDMA),   Time-Division Multiple Access (TDMA), and Time-Division Duplex (TDD)   techniques.  The coverage distance is from 70 meters (indoors) to 600   meters (outdoors).   In its generic network topology, DECT is defined as a cellular   network technology.  However, the most common configuration is a star   network with a single Fixed Part (FP) defining the network with a   number of Portable Parts (PPs) attached.  The Medium Access Control   (MAC) layer supports classical DECT as this is used for services like   discovery, pairing, and security features.  All these features have   been reused from DECT.   The DECT-ULE device can switch to the ULE mode of operation,   utilizing the new Ultra Low Energy (ULE) MAC layer features.  The   DECT-ULE Data Link Control (DLC) provides multiplexing as well as   segmentation and re-assembly for larger packets from layers above.   The DECT-ULE layer also implements per-message authentication and   encryption.  The DLC layer ensures packet integrity and preserves   packet order, but delivery is based on best effort.   The current DECT-ULE MAC layer standard supports low bandwidth data   broadcast.  However, the usage of this broadcast service has not yet   been standardized for higher layers [RFC8105].  DECT-ULE can be used   for smart metering in a home.2.4.  MS/TP   MS/TP is a MAC protocol for the RS-485 [TIA-485-A] physical layer and   is used primarily in building automation networks.   An MS/TP device is typically based on a low-cost microcontroller with   limited processing power and memory.  These constraints, together   with low data rates and a small MAC address space, are similar to   those faced in 6LoWPAN networks.  MS/TP differs significantly from   6LoWPAN in at least three respects:   a.  MS/TP devices are typically mains powered.   b.  All MS/TP devices on a segment can communicate directly, so there       are no hidden node issues or mesh routing issues.   c.  The latest MS/TP specification provides support for large       payloads, eliminating the need for fragmentation and reassembly       below IPv6.   MS/TP is designed to enable multidrop networks over shielded twisted   pair wiring.  It can support network segments up to 1000 meters in   length at a data rate of 115.2 kbit/s or segments up to 1200 meters   in length at lower bit rates.  An MS/TP interface requires only a   Universal Asynchronous Receiver Transmitter (UART), an RS-485   [TIA-485-A] transceiver with a driver that can be disabled, and a 5   ms resolution timer.  The MS/TP MAC is typically implemented in   software.   Because of its long range (~1 km), MS/TP can be used to connect   remote devices (such as district heating controllers) to the nearest   building control infrastructure over a single link [RFC8163].2.5.  NFC   NFC technology enables secure interactions between electronic   devices, allowing consumers to perform contactless transactions,   access digital content, and connect electronic devices with a single   touch [LLCP-1.4].  The distance between sender and receiver is 10 cm   or less.  NFC complements many popular consumer-level wireless   technologies by utilizing the key elements in existing standards for   contactless card technology.   Extending the capability of contactless card technology, NFC also   enables devices to share information at a distance that is less than   10 cm with a maximum communication speed of 424 kbps.  Users can   share business cards, make transactions, access information from a   smart poster, or provide credentials for access control systems with   a simple touch.   NFC's bidirectional communication ability is suitable for   establishing connections with other technologies by the simplicity of   touch.  In addition to the easy connection and quick transactions,   simple data sharing is available [RFC9428].  NFC can be used for   secure transfer services where privacy is important.2.6.  PLC   PLC is a data transmission technique that utilizes power conductors   as the medium [RFC9354].  Unlike other dedicated communication   infrastructure, power conductors are widely available indoors and   outdoors.  Moreover, wired technologies cause less interference to   the radio medium than wireless technologies and are more reliable   than their wireless counterparts.   The table below shows some available open standards defining PLC.   +=============+=================+============+===========+==========+   | PLC Systems | Frequency Range |    Type    |    Data   | Distance |   |             |                 |            |    Rate   |          |   +=============+=================+============+===========+==========+   |  IEEE 1901  |    < 100 MHz    | Broadband  |    200    |  1000 m  |   |             |                 |            |    Mbps   |          |   +-------------+-----------------+------------+-----------+----------+   | IEEE 1901.1 |     < 12 MHz    |  PLC-IoT   |     10    |  2000 m  |   |             |                 |            |    Mbps   |          |   +-------------+-----------------+------------+-----------+----------+   | IEEE 1901.2 |    < 500 kHz    | Narrowband |    200    |  3000 m  |   |             |                 |            |    kbps   |          |   +-------------+-----------------+------------+-----------+----------+   |    G3-PLC   |    < 500 kHz    | Narrowband |    234    |  3000 m  |   |             |                 |            |    kbps   |          |   +-------------+-----------------+------------+-----------+----------+               Table 1: Some Available Open Standards in PLC   IEEE Std 1901 [IEEE-1901] defines a broadband variant of PLC, but it   is only effective within short range.  This standard addresses the   requirements of high data rates such as the Internet, HDTV, audio,   and gaming.   IEEE Std 1901.1 [IEEE-1901.1] defines a medium frequency band (less   than 12 MHz) broadband PLC technology for smart grid applications   based on Orthogonal Frequency Division Multiplexing (OFDM).  By   achieving an extended communication range with medium speeds, this   standard can be applied in both indoor and outdoor scenarios, such as   Advanced Metering Infrastructure (AMI), street lighting, electric   vehicle charging, and a smart city.   IEEE Std 1901.2 [IEEE-1901.2] defines a narrowband variant of PLC   with a lower data rate but a significantly higher transmission range   that could be used in an indoor or even an outdoor environment.  A   typical use case of PLC is a smart grid.   G3-PLC [G3-PLC] is a narrowband PLC technology that is based on the   ITU-T G.9903 Recommendation [G.9903].  The ITU-T G.9903   Recommendation contains the physical layer and data link-layer   specification for the G3-PLC narrowband OFDM power line communication   transceivers, for communications via alternating current and direct   current electric power lines over frequency bands below 500 kHz.2.7.  Comparison between 6lo Link-Layer Technologies   In the above subsections, various 6lo link-layer technologies are   described.  The following table shows the dominant parameters of each   use case corresponding to the 6lo link-layer technology.   +=========+========+===========+========+========+========+=========+   |         | Z-Wave | Bluetooth |DECT-ULE| MS/TP  |  NFC   |   PLC   |   |         |        |     LE    |        |        |        |         |   +=========+========+===========+========+========+========+=========+   |  Usage  |  Home  |  Interact | Meter  |Building| Secure |  Smart  |   |         | Autom. |  w/ Smart |Reading | Autom. |Transfer|   Grid  |   |         |        |   Phone   |        |        |        |         |   +=========+--------+-----------+--------+--------+--------+---------+   | Topology|L2-mesh |   Star &  | Star,  | MS/TP, |  P2P,  |Star Tree|   |    &    |   or   |    Mesh   |No mesh |No mesh |L2-mesh |   Mesh  |   |  Subnet |L3-mesh |           |        |        |        |         |   +=========+--------+-----------+--------+--------+--------+---------+   | Mobility|   No   |    Yes    |   No   |   No   |  Yes   |    No   |   |   Req.  |        |           |        |        |        |         |   +=========+--------+-----------+--------+--------+--------+---------+   |Buffering|  Yes   |    Yes    |  Yes   |  Yes   |  Yes   |   Yes   |   |   Req.  |        |           |        |        |        |         |   +=========+--------+-----------+--------+--------+--------+---------+   | Latency,|  Yes   |    Yes    |  Yes   |  Yes   |  Yes   |   Yes   |   | QoS Req.|        |           |        |        |        |         |   +=========+--------+-----------+--------+--------+--------+---------+   | Frequent|   No   |     No    |   No   |  Yes   |   No   |    No   |   | Tx Req. |        |           |        |        |        |         |   +=========+--------+-----------+--------+--------+--------+---------+   |   RFC   |RFC 7428|  RFC 7668 |RFC 8105|RFC 8163|RFC 9428| RFC 9354|   |         |        |  RFC 9159 |        |        |        |         |   +=========+--------+-----------+--------+--------+--------+---------+          Table 2: Comparison between 6lo Link-Layer Technologies3.  Guidelines for Adopting an IPv6 Stack (6lo)   6lo aims to reuse and/or adapt existing 6LoWPAN functionality in   order to efficiently support IPv6 over a variety of IoT L2   technologies.  The following guideline targets new candidate-   constrained L2 technologies that may be considered for running a   modified 6LoWPAN stack on top.  The modification of the 6LoWPAN stack   should be based on the following:   Addressing Model:      The addressing model determines whether the device is capable of      forming IPv6 link-local and global addresses, and what is the best      way to derive the IPv6 addresses for the constrained L2 devices.      IPv6 addresses that are derived from an L2 address are specified      in [RFC4944], but there are implications for privacy.  The reason      is that the L2 address in 6lo link-layer technologies is a little      short, and devices can become vulnerable to the various threats.      For global usage, a unique IPv6 address must be derived using an      assigned prefix and a unique interface ID.  [RFC8065] provides      such guidelines.  For MAC-derived IPv6 addresses, refer to      [RFC8163] for mapping examples.  Broadcast and multicast support      are dependent on the L2 networks.  Most low-power L2      implementations map multicast to broadcast networks.  So care must      be taken in the design for when to use broadcast, trying to stick      to unicast messaging whenever possible.   MTU Considerations:      The deployment should consider packet maximum transmission unit      (MTU) needs over the link layer and should consider if      fragmentation and reassembly of packets are needed at the 6LoWPAN      layer.  For example, if the link layer supports fragmentation and      reassembly of packets, then the 6LoWPAN layer may not need to      support fragmentation and reassembly.  In fact, for greatest      efficiency, choosing a low-power link layer that can carry      unfragmented application packets would be optimal for packet      transmission if the deployment can afford it.  Please refer to 6lo      RFCs [RFC7668], [RFC8163], and [RFC8105] for example guidance.   Mesh or L3 Routing:      6LoWPAN specifications provide mechanisms to support mesh routing      at L2, a configuration called "mesh-under" [RFC6606].  It is also      possible to use an L3 routing protocol in 6LoWPAN, an approach      known as "route-over".  [RFC6550] defines RPL, an L3 routing      protocol for low-power and lossy networks using directed acyclic      graphs. 6LoWPAN is routing-protocol-agnostic and does not specify      any particular L2 or L3 routing protocol to use with a 6LoWPAN      stack.   Address Assignment:      6LoWPAN developed a new version of IPv6 Neighbor Discovery      [RFC4861] [RFC4862]. 6LoWPAN Neighbor Discovery [RFC6775]      [RFC8505] inherits from IPv6 Neighbor Discovery for mechanisms      such as Stateless Address Autoconfiguration (SLAAC) and Neighbor      Unreachability Detection (NUD).  A 6LoWPAN node is also expected      to be an IPv6 host per [RFC8200], which means it should ignore      consumed routing headers and hop-by-hop options.  When operating      in an RPL network [RFC6550], it is also beneficial to support IP-      in-IP encapsulation [RFC9008].  The 6LoWPAN node should also      support the registration extensions defined in [RFC8505] and use      the mechanism as the default Neighbor Discovery method.  It is the      responsibility of the deployment to ensure unique global IPv6      addresses for Internet connectivity.  For local-only connectivity,      IPv6 Unique Local Address (ULA) may be used.  [RFC6775] and      [RFC8505] specify the 6LoWPAN Border Router (6LBR), which is      responsible for prefix assignment to the 6LoWPAN network.  A 6LBR      can be connected to the Internet or to an enterprise network via      one of the interfaces.  Please refer to [RFC7668] and [RFC8105]      for examples of address assignment considerations.  In addition,      privacy considerations in [RFC8065] must be consulted for      applicability.  In certain scenarios, the deployment may not      support IPv6 address autoconfiguration due to regulatory and      business reasons and may choose to offer a separate address      assignment service.  Address-Protected Neighbor Discovery      [RFC8928] enables source address validation [RFC6620] and protects      the address ownership against impersonation attacks.   Broadcast Avoidance:      6LoWPAN Neighbor Discovery aims to reduce the amount of multicast      traffic of classic Neighbor Discovery, since IP-level multicast      translates into L2 broadcast in many L2 technologies [RFC6775].      6LoWPAN Neighbor Discovery relies on a proactive registration to      avoid the use of multicast for address resolution.  It also uses a      unicast method for Duplicate Address Detection (DAD) and avoids      multicast lookups from all nodes by using non-onlink prefixes.      Router Advertisements (RAs) are also sent in unicast, in response      to Router Solicitations (RSs).   Host-to-Router Interface:      6lo has defined registration extensions for 6LoWPAN Neighbor      Discovery [RFC8505].  This effort provides a host-to-router      interface by which a host can request its router to ensure      reachability for the address registered with the router.  Note      that functionality has been developed to ensure that such a host      can benefit from routing services in a RPL network [RFC9010].   Proxy Neighbor Discovery:      Further functionality also allows a device (e.g., an energy-      constrained device that needs to sleep most of the time) to      request proxy Neighbor Discovery services from a 6LoWPAN Backbone      Router (6BBR) [RFC8505] [RFC8929].  The latter RFC federates a      number of links into a multi-link subnet.   Header Compression:      IPv6 header compression [RFC6282] is a vital part of IPv6 over      low-power communication.  Examples of header compression over      different link-layer specifications are found in [RFC7668],      [RFC8163], and [RFC8105].  A generic header compression technique      is specified in [RFC7400].  For 6LoWPAN networks where RPL is the      routing protocol, there are 6LoWPAN header compression extensions      that allow compressing the RPL artifacts used when forwarding      packets in the route-over mesh [RFC8138] [RFC9035].   Security and Encryption:      Though 6LoWPAN basic specifications do not address security at the      network layer, the assumption is that L2 security must be present.      Nevertheless, care must be taken since specific L2 technologies      may exhibit security gaps.  Typically, 6lo L2 technologies (see      Section 2) offer security properties such as confidentiality and/      or message authentication.  In addition, end-to-end security is      highly desirable.  Protocols such as DTLS/TLS, as well as Object      Security, are being used in the constrained-node network domain      [SEC-PROT-COMP].  The relevant IETF working groups should be      consulted for application and transport level security.  The IETF      has worked on address authentication [RFC8928], and secure      bootstrapping is also being discussed in the IETF.  However, there      may be other security mechanisms available in a deployment through      other standards, such as hardware-level security or certificates      for the initial booting process.  In order to use security      mechanisms, the implementation needs to be able to afford it in      terms of processing capabilities and energy consumption.   Additional Processing:      [RFC8066] defines guidelines for ESC dispatch octets used in the      6LoWPAN header.  The ESC type is defined to use additional      dispatch octets in the 6LoWPAN header.  An implementation may take      advantage of the ESC header to offer a deployment-specific      processing of 6LoWPAN packets.4.  6lo Deployment Examples4.1.  Wi-SUN Usage of 6lo in Network Layer   Wireless Smart Ubiquitous Network (Wi-SUN) [Wi-SUN] is a technology   based on IEEE Std 802.15.4g [IEEE-802.15.4].  Wi-SUN networks support   star and mesh topologies as well as hybrid star/mesh deployments, but   these are typically laid out in a mesh topology where each node   relays data for the network to provide network connectivity.  Wi-SUN   networks are deployed on both grid-powered and battery-operated   devices [RFC8376].   The main application domains using Wi-SUN are smart utility and smart   city networks.  The Wi-SUN Alliance Field Area Network (FAN)   primarily covers outdoor networks.  The Wi-SUN FAN specification   defines an IPv6-based protocol suite that includes TCP/UDP, IPv6, 6lo   adaptation layer, DHCPv6 for IPv6 address management, RPL, and   ICMPv6.4.2.  Thread Usage of 6lo in the Network Layer   Thread is an IPv6-based networking protocol stack built on open   standards, designed for smart home environments, and based on low-   power IEEE Std 802.15.4 mesh networks.  Because of its IPv6   foundation, Thread can support existing popular application layers   and IoT platforms, provide end-to-end security, ease development, and   enable flexible designs [Thread].   The Thread specification uses the IEEE Std 802.15.4 [IEEE-802.15.4]   physical and MAC layers operating at 250 kbps in the 2.4 GHz band.   Thread devices use 6LoWPAN, as defined in [RFC4944] and [RFC6282],   for transmission of IPv6 packets over IEEE Std 802.15.4 networks.   Header compression is used within the Thread network, and devices   transmitting messages compress the IPv6 header to minimize the size   of the transmitted packet.  The mesh header is supported for link-   layer (i.e., mesh-under) forwarding.  The mesh header as used in   Thread also allows efficient end-to-end fragmentation of messages   rather than the hop-by-hop fragmentation specified in [RFC4944].   Mesh-under routing in Thread is based on a distance vector protocol   in a full mesh topology.4.3.  G3-PLC Usage of 6lo in Network Layer   G3-PLC [G3-PLC] is a narrowband PLC technology that is based on the   ITU-T G.9903 Recommendation [G.9903].  G3-PLC supports multi-hop mesh   network topology and facilitates highly reliable, long-range   communication.  With the abilities to support IPv6 and to cross   transformers, G3-PLC is regarded as one of the next-generation   narrowband PLC technologies.  G3-PLC has got massive deployments over   several countries, e.g., Japan and France.   The main application domains using G3-PLC are smart grid and smart   cities.  This includes, but is not limited to, the following   applications:   *  smart metering   *  vehicle-to-grid communication   *  demand response   *  distribution automation   *  home/building energy management systems   *  smart street lighting   *  AMI backbone network   *  wind/solar farm monitoring   In the G3-PLC specification, the 6lo adaption layer utilizes the   6LoWPAN functions (e.g., header compression, fragmentation, and   reassembly).  However, due to the different characteristics of the   PLC media, the 6LoWPAN adaptation layer cannot perfectly fulfill the   requirements [RFC9354].  The ESC dispatch type is used in the G3-PLC   to provide fundamental mesh routing and bootstrapping functionalities   [RFC8066].4.4.  Netricity Usage of 6lo in the Network Layer   The Netricity program in the HomePlug Powerline Alliance [NETRICITY]   promotes the adoption of products built on the IEEE Std 1901.2 low-   frequency narrowband PLC standard [IEEE-1901.2], which provides for   urban and long-distance communications and propagation through   transformers of the distribution network using frequencies below 500   kHz.  The technology also addresses requirements that assure   communication privacy and secure networks.   The main application domains using Netricity are smart grid and smart   cities.  This includes, but is not limited to, the following   applications:   *  utility grid modernization   *  distribution automation   *  meter-to-grid connectivity   *  microgrids   *  grid sensor communications   *  load control   *  demand response   *  net metering   *  street lighting control   *  photovoltaic panel monitoring   The Netricity system architecture is based on the physical and MAC   layers of IEEE Std 1901.2.  Regarding the 6lo adaptation layer and an   IPv6 network layer, Netricity utilizes IPv6 protocol suite including   6lo/6LoWPAN header compression, DHCPv6 for IP address management, RPL   routing protocol, ICMPv6, and unicast/multicast forwarding.  Note   that the L3 routing in Netricity uses RPL in non-storing mode with   the MRHOF (Minimum Rank with Hysteresis Objective Function) based on   their own defined Estimated Transmission Time (ETT) metric.5.  6lo Use-Case Examples   As IPv6 stacks for constrained-node networks use a variation of the   6LoWPAN stack applied to each particular link-layer technology,   various 6lo use cases can be provided.  In this section, various 6lo   use cases, which are based on different link-layer technologies, are   described.5.1.  Use Case of ITU-T G.9959: Smart Home   Z-Wave is one of the main technologies that may be used to enable   smart home applications.  Born as a proprietary technology, Z-Wave   was specifically designed for this particular use case.  Recently,   the Z-Wave radio interface (physical and MAC layers) has been   standardized as the ITU-T G.9959 specification [G.9959].   Example: Use of ITU-T G.9959 for Home Automation      A variety of home devices (e.g., light dimmers/switches, plugs,      thermostats, blinds/curtains, and remote controls) are augmented      with ITU-T G.9959 interfaces.  A user may turn home appliances on      and off, or the user may control them by pressing a wall switch or      a button on a remote control.  Scenes may be programmed so that      the home devices adopt a specific configuration after a given      event.  Sensors may also periodically send measurements of several      parameters (e.g., gas presence, light, temperature, humidity),      which are collected at a sink device, or may generate commands for      actuators (e.g., a smoke sensor may send an alarm message to a      safety system).   The devices involved in the described scenario are nodes of a network   that follows the mesh topology, which is suitable for path diversity   to face indoor multipath propagation issues.  The multi-hop paradigm   allows end-to-end connectivity when direct range communication is not   possible.5.2.  Use Case of Bluetooth LE: Smartphone-Based Interaction   The key feature behind the current high Bluetooth LE momentum is its   support in a large majority of smartphones in the market.  Bluetooth   LE can be used to allow interaction between a smartphone and   surrounding sensors or actuators.  Furthermore, Bluetooth LE is also   the main radio interface currently available in wearables.  Since a   smartphone typically has several radio interfaces that provide   Internet access, such as Wi-Fi or cellular, a smartphone can act as a   gateway for nearby devices, such as sensors, actuators, or wearables.   Bluetooth LE may be used in several domains, including healthcare,   sports/wellness, and home automation.   Example: Use of a Body Area Network Based on Bluetooth LE for Fitness      A person wears a smartwatch for fitness purposes.  The smartwatch      has several sensors (e.g., heart rate, accelerometer, gyrometer,      GPS, and temperature), a display, and a Bluetooth LE radio      interface.  The smartwatch can show fitness-related statistics on      its display.  However, when a paired smartphone is in range of the      smartwatch, the latter can report almost real-time measurements of      its sensors to the smartphone, which can forward the data to a      cloud service on the Internet. 6lo enables this use case by      providing efficient end-to-end IPv6 support.  In addition, the      smartwatch can receive notifications (e.g., alarm signals) from      the cloud service via the smartphone.  On the other hand, the      smartphone may locally generate messages for the smartwatch, such      as e-mail reception or calendar notifications.   The functionality supported by the smartwatch may be complemented by   other devices, such as other on-body sensors, wireless headsets, or   head-mounted displays.  All such devices may connect to the   smartphone, creating a star topology network whereby the smartphone   is the central component.  Support for extended network topologies   (e.g., mesh networks) is being developed as of the writing of this   document.5.3.  Use Case of DECT-ULE: Smart Home   DECT is a technology widely used for wireless telephone   communications in residential scenarios.  Since DECT-ULE is a low-   power variant of DECT, DECT-ULE can be used to connect constrained   devices (such as sensors and actuators) to a Fixed Part (FP), a   device that typically acts as a base station for wireless telephones.   In this case, additionally, the FP must have a data network   connection.  Therefore, DECT-ULE is especially suitable for the   connected home space in application areas such as home automation,   smart metering, safety, and healthcare.  Since DECT-ULE uses   dedicated bandwidth, it avoids this coexistence issues suffered by   other technologies that use, for example, Industrial, Scientific, and   Medical (ISM) frequency bands.   Example: Use of DECT-ULE for Smart Metering      The smart electricity meter of a home is equipped with a DECT-ULE      transceiver.  This device is in the coverage range of the FP of      the home.  The FP can act as a router connected to the Internet.      This way, the smart meter can transmit electricity consumption      readings through the DECT-ULE link with the FP, and the latter can      forward such readings to the utility company using Wide Area      Network (WAN) links.  The meter can also receive queries from the      utility company or from an advanced energy control system      controlled by the user, which may also be connected to the FP via      DECT-ULE.5.4.  Use Case of MS/TP: Building Automation Networks   The primary use case for IPv6 over MS/TP (6LoBAC) is in building   automation networks.  [BACnet] is the open, international standard   protocol for building automation, and MS/TP is defined in [BACnet]   Clause 9.  MS/TP was designed to be a low-cost, multi-drop field bus   to interconnect the most numerous elements (sensors and actuators) of   a building automation network to their controllers.  A key aspect of   6LoBAC is that it is designed to co-exist with BACnet MS/TP on the   same link, easing the ultimate transition of some BACnet networks to   fundamental end-to-end IPv6 transport protocols.  New applications   for 6LoBAC may be found in other domains where low cost, long   distance, and low latency are required.  Note that BACnet comprises   various networking solutions other than MS/TP, including the recently   emerged BACnet IP.  However, the latter is based on high-speed   Ethernet infrastructure, and it is outside of the constrained-node   network scope.   Example: Use of 6LoBAC in Building Automation Networks      The majority of installations for MS/TP are for "terminal" or      "unitary" controllers, i.e., single zone or room controllers that      may connect to HVAC or other controls such as lighting or blinds.      The economics of daisy chaining a single twisted pair between      multiple devices is often preferred over home-run, Cat-5-style      wiring.   A multi-zone controller might be implemented as an IP router between   a classical Ethernet link and several 6LoBAC links, fanning out to   multiple terminal controllers.   The superior distance capabilities of MS/TP (~1 km) compared to other   6lo media may suggest its use in applications to connect remote   devices to the nearest building infrastructure.  For example, remote   pumping or measuring stations with moderate bandwidth requirements   can benefit from the low-cost and robust capabilities of MS/TP over   other wired technologies such as DSL, without the line-of-sight   restrictions or hop-by-hop latency of many low-cost wireless   solutions.5.5.  Use Case of NFC: Alternative Secure Transfer   In different applications, a variety of secured data can be handled   and transferred.  Depending on the security level of the data,   different transfer methods can be alternatively selected.   Example: Use of NFC for Secure Transfer in Healthcare Services with   Tele-Assistance      An older adult who lives alone wears one to several wearable 6lo      devices to measure heartbeat, pulse rate, etc.  Other 6lo devices      are densely installed at home for movement detection.  A 6LBR at      home will send the sensed information to a connected healthcare      center.  Portable base stations with displays may be used to check      the data at home, as well.  Data is gathered in both periodic and      event-driven fashion.  In this application, event-driven data can      be very time critical.  In addition, privacy becomes a serious      issue in this case, as the sensed data is very personal.   While the older adult is provided audio and video healthcare services   by a tele-assistance based on cellular connections, the older adult   can alternatively use NFC connections to transfer the personal sensed   data to the tele-assistance.  Hackers can overhear the data based on   the cellular connection, but they cannot gather the personal data   over the NFC connection.5.6.  Use Case of PLC: Smart Grid   The smart grid concept is based on deploying numerous operational and   energy measuring subsystems in an electricity grid system.  It   comprises multiple administrative levels and segments to provide   connectivity among these numerous components.  Last mile connectivity   is established over the Low-Voltage segment, whereas connectivity   over electricity distribution takes place over the High-Voltage   segment.  Smart grid systems include AMI, Demand Response, Home   Energy Management System, and Wide Area Situational Awareness (WASA),   among others.   Although other wired and wireless technologies are also used in a   smart grid, PLC benefits from reliable data communication over   electrical power lines that are already present, and the deployment   cost can be comparable to wireless technologies.  The 6lo-related   scenarios for PLC mainly lie in the Low-Voltage PLC networks with   most applications in the area of advanced metering infrastructure,   vehicle-to-grid communications, in-home energy management, and smart   street lighting.   Example: Use of PLC for AMI      Household electricity meters transmit time-based data of electric      power consumption through PLC.  Data concentrators receive all the      meter data in their corresponding living districts and send them      to the Meter Data Management System through a WAN network (e.g.,      Medium-Voltage PLC, Ethernet, or General Packet Radio Service      (GPRS)) for storage and analysis.  Two-way communications are      enabled, which means smart meters can perform actions like      notification of electricity charges according to the commands from      the utility company.   With the existing power line infrastructure as a communication   medium, the cost of building up the PLC network is naturally saved,   and more importantly, labor and operational costs can be minimized   from a long-term perspective.  Furthermore, this AMI application   speeds up electricity charging, reduces losses by restraining power   theft, and helps to manage the health of the grid based on line loss   analysis.   Example: Use of PLC (IEEE Std 1901.1) for WASA in a Smart Grid      Many subsystems of a smart grid require low data rates, and      narrowband variants (e.g., IEEE Std 1901.1) of PLC fulfill such      requirements.  Recently, more complex scenarios are emerging that      require higher data rates.   A WASA subsystem is an appropriate example that collects large   amounts of information about the current state of the grid over a   wide area from electric substations as well as power transmission   lines.  The collected feedback is used for monitoring, controlling,   and protecting all the subsystems.6.  IANA Considerations   This document has no IANA actions.7.  Security Considerations   This document does not create security concerns in addition to those   described in the Security Considerations sections of the 6lo   adaptation layers considered in this document [RFC7428], [RFC7668],   [RFC8105], [RFC8163], [RFC9159], [RFC9428], and [RFC9354].   Neighbor Discovery in 6lo links may be susceptible to threats as   detailed in [RFC3756].  Mesh routing is expected to be common in some   6lo networks, such as ITU-T G.9959 networks, Bluetooth LE mesh   networks, and PLC networks.  This implies additional threats due to   ad hoc routing as per [KW03].  Most of the L2 technologies considered   in this document (i.e., ITU-T G.9959, Bluetooth LE, DECT-ULE, and   PLC) support link-layer security.  Making use of such provisions will   alleviate the threats mentioned above.  Note that NFC is often   considered to offer intrinsic security properties due to its short   link range.  MS/TP does not support link-layer security, since in its   original BACnet protocol stack, security is provided at the network   layer; thus, alternative security functionality needs to be used for   a 6lo-based protocol stack over MS/TP.   End-to-end communication is expected to be secured by means of common   mechanisms, such as IPsec, DTLS/TLS, Object Security [RFC8613], and   Ephemeral Diffie-Hellman Over COSE (EDHOC) [EDHOC].   The 6lo stack uses the IPv6 addressing model.  The implications for   privacy and network performance of using L2-address-derived IPv6   addresses need to be considered [RFC8065].8.  References8.1.  Normative References   [RFC4861]  Narten, T., Nordmark, E., Simpson, W., and H. Soliman,              "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,              DOI 10.17487/RFC4861, September 2007,              <https://www.rfc-editor.org/info/rfc4861>.   [RFC4862]  Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless              Address Autoconfiguration", RFC 4862,              DOI 10.17487/RFC4862, September 2007,              <https://www.rfc-editor.org/info/rfc4862>.   [RFC4919]  Kushalnagar, N., Montenegro, G., and C. Schumacher, "IPv6              over Low-Power Wireless Personal Area Networks (6LoWPANs):              Overview, Assumptions, Problem Statement, and Goals",              RFC 4919, DOI 10.17487/RFC4919, August 2007,              <https://www.rfc-editor.org/info/rfc4919>.   [RFC4944]  Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler,              "Transmission of IPv6 Packets over IEEE 802.15.4              Networks", RFC 4944, DOI 10.17487/RFC4944, September 2007,              <https://www.rfc-editor.org/info/rfc4944>.   [RFC6568]  Kim, E., Kaspar, D., and JP. Vasseur, "Design and              Application Spaces for IPv6 over Low-Power Wireless              Personal Area Networks (6LoWPANs)", RFC 6568,              DOI 10.17487/RFC6568, April 2012,              <https://www.rfc-editor.org/info/rfc6568>.   [RFC6606]  Kim, E., Kaspar, D., Gomez, C., and C. Bormann, "Problem              Statement and Requirements for IPv6 over Low-Power              Wireless Personal Area Network (6LoWPAN) Routing",              RFC 6606, DOI 10.17487/RFC6606, May 2012,              <https://www.rfc-editor.org/info/rfc6606>.   [RFC7228]  Bormann, C., Ersue, M., and A. Keranen, "Terminology for              Constrained-Node Networks", RFC 7228,              DOI 10.17487/RFC7228, May 2014,              <https://www.rfc-editor.org/info/rfc7228>.   [RFC7400]  Bormann, C., "6LoWPAN-GHC: Generic Header Compression for              IPv6 over Low-Power Wireless Personal Area Networks              (6LoWPANs)", RFC 7400, DOI 10.17487/RFC7400, November              2014, <https://www.rfc-editor.org/info/rfc7400>.   [RFC7428]  Brandt, A. and J. Buron, "Transmission of IPv6 Packets              over ITU-T G.9959 Networks", RFC 7428,              DOI 10.17487/RFC7428, February 2015,              <https://www.rfc-editor.org/info/rfc7428>.   [RFC7668]  Nieminen, J., Savolainen, T., Isomaki, M., Patil, B.,              Shelby, Z., and C. Gomez, "IPv6 over BLUETOOTH(R) Low              Energy", RFC 7668, DOI 10.17487/RFC7668, October 2015,              <https://www.rfc-editor.org/info/rfc7668>.   [RFC8105]  Mariager, P., Petersen, J., Ed., Shelby, Z., Van de Logt,              M., and D. Barthel, "Transmission of IPv6 Packets over              Digital Enhanced Cordless Telecommunications (DECT) Ultra              Low Energy (ULE)", RFC 8105, DOI 10.17487/RFC8105, May              2017, <https://www.rfc-editor.org/info/rfc8105>.   [RFC8163]  Lynn, K., Ed., Martocci, J., Neilson, C., and S.              Donaldson, "Transmission of IPv6 over Master-Slave/Token-              Passing (MS/TP) Networks", RFC 8163, DOI 10.17487/RFC8163,              May 2017, <https://www.rfc-editor.org/info/rfc8163>.   [RFC8200]  Deering, S. and R. Hinden, "Internet Protocol, Version 6              (IPv6) Specification", STD 86, RFC 8200,              DOI 10.17487/RFC8200, July 2017,              <https://www.rfc-editor.org/info/rfc8200>.   [RFC9159]  Gomez, C., Darroudi, S.M., Savolainen, T., and M. Spoerk,              "IPv6 Mesh over BLUETOOTH(R) Low Energy Using the Internet              Protocol Support Profile (IPSP)", RFC 9159,              DOI 10.17487/RFC9159, December 2021,              <https://www.rfc-editor.org/info/rfc9159>.   [RFC9354]  Hou, J., Liu, B., Hong, Y-G., Tang, X., and C. Perkins,              "Transmission of IPv6 Packets over Power Line              Communication (PLC) Networks", RFC 9354,              DOI 10.17487/RFC9354, January 2023,              <https://www.rfc-editor.org/info/rfc9354>.8.2.  Informative References   [BACnet]   ASHRAE, "BACnet-A Data Communication Protocol for Building              Automation and Control Networks (ANSI Approved)", ASHRAE              Standard 135-2020, October 2020,              <https://www.techstreet.com/standards/ashrae-              135-2020?product_id=2191852>.   [BTCorev5.4]              Bluetooth, "Core Specification Version 5.4", January 2012,              <https://www.bluetooth.com/specifications/specs/core-              specification-5-4/>.   [EDHOC]    Selander, G., Preuß Mattsson, J., and F. Palombini,              "Ephemeral Diffie-Hellman Over COSE (EDHOC)", Work in              Progress, Internet-Draft, draft-ietf-lake-edhoc-22, 25              August 2023, <https://datatracker.ietf.org/doc/html/draft-              ietf-lake-edhoc-22>.   [G.9903]   ITU-T, "Narrowband orthogonal frequency division              multiplexing power line communication transceivers for              G3-PLC networks", ITU-T Recommendation G.9903, August              2017, <https://www.itu.int/rec/T-REC-G.9903-201708-I/en>.   [G.9959]   ITU-T, "Short range narrow-band digital radiocommunication              transceivers - PHY, MAC, SAR and LLC layer              specifications", ITU-T Recommendation G.9959, January              2015, <https://www.itu.int/rec/T-REC-G.9959-201501-I/en>.   [G3-PLC]   "G3-Alliance", <https://g3-plc.com>.   [IEEE-1901]              IEEE, "IEEE Standard for Broadband over Power Line              Networks: Medium Access Control and Physical Layer              Specifications", DOI 10.1109/IEEESTD.2010.5678772, IEEE              Std 1901-2010, December 2010,              <https://standards.ieee.org/ieee/1901/4953/>.   [IEEE-1901.1]              IEEE, "IEEE Standard for Medium Frequency (less than 12              MHz) Power Line Communications for Smart Grid              Applications", DOI 10.1109/IEEESTD.2018.8360785, IEEE              Std 1901.1-2018, May 2018,              <https://ieeexplore.ieee.org/document/8360785>.   [IEEE-1901.2]              IEEE, "IEEE Standard for Low-Frequency (less than 500 kHz)              Narrowband Power Line Communications for Smart Grid              Applications", DOI 10.1109/IEEESTD.2013.6679210, IEEE              Std 1901.2-2013, December 2013,              <https://standards.ieee.org/ieee/1901.2/4833/>.   [IEEE-802.15.4]              IEEE, "IEEE Standard for Low-Rate Wireless Networks",              DOI 10.1109/IEEESTD.2020.9144691, IEEE Std 802.15.4-2020,              July 2020,              <https://standards.ieee.org/ieee/802.15.4/7029/>.   [IEEE-802.15.9]              IEEE, "IEEE Standard for Transport of Key Management              Protocol (KMP) Datagrams",              DOI 10.1109/IEEESTD.2022.9690134, IEEE Std 802.15.9-2021,              January 2022,              <https://ieeexplore.ieee.org/document/9690134>.   [IPSP]     Bluetooth, "Internet Protocol Support Profile 1.0",              December 2014,              <https://www.bluetooth.com/specifications/specs/internet-              protocol-support-profile-1-0/>.   [KW03]     Karlof, C. and D. Wagner, "Secure routing in wireless              sensor networks: attacks and countermeasures", Volume 1,              Issues 2-3, Pages 293-315,              DOI 10.1016/S1570-8705(03)00008-8, September 2003,              <https://doi.org/10.1016/S1570-8705(03)00008-8>.   [LLCP-1.4] NFC Forum, "Logical Link Control Protocol Technical              Specification", Version 1.4, December 2022, <https://nfc-              forum.org/build/specifications/logical-link-control-              protocol-technical-specification/>.   [NETRICITY]              Netricity, "The Netricity program addresses the need for              long range powerline networking for outside-the-home,              smart meter-to-grid, and industrial control applications",              <https://www.netricity.org/>.   [RFC3756]  Nikander, P., Ed., Kempf, J., and E. Nordmark, "IPv6              Neighbor Discovery (ND) Trust Models and Threats",              RFC 3756, DOI 10.17487/RFC3756, May 2004,              <https://www.rfc-editor.org/info/rfc3756>.   [RFC6282]  Hui, J., Ed. and P. Thubert, "Compression Format for IPv6              Datagrams over IEEE 802.15.4-Based Networks", RFC 6282,              DOI 10.17487/RFC6282, September 2011,              <https://www.rfc-editor.org/info/rfc6282>.   [RFC6550]  Winter, T., Ed., Thubert, P., Ed., Brandt, A., Hui, J.,              Kelsey, R., Levis, P., Pister, K., Struik, R., Vasseur,              JP., and R. Alexander, "RPL: IPv6 Routing Protocol for              Low-Power and Lossy Networks", RFC 6550,              DOI 10.17487/RFC6550, March 2012,              <https://www.rfc-editor.org/info/rfc6550>.   [RFC6620]  Nordmark, E., Bagnulo, M., and E. Levy-Abegnoli, "FCFS              SAVI: First-Come, First-Served Source Address Validation              Improvement for Locally Assigned IPv6 Addresses",              RFC 6620, DOI 10.17487/RFC6620, May 2012,              <https://www.rfc-editor.org/info/rfc6620>.   [RFC6775]  Shelby, Z., Ed., Chakrabarti, S., Nordmark, E., and C.              Bormann, "Neighbor Discovery Optimization for IPv6 over              Low-Power Wireless Personal Area Networks (6LoWPANs)",              RFC 6775, DOI 10.17487/RFC6775, November 2012,              <https://www.rfc-editor.org/info/rfc6775>.   [RFC8065]  Thaler, D., "Privacy Considerations for IPv6 Adaptation-              Layer Mechanisms", RFC 8065, DOI 10.17487/RFC8065,              February 2017, <https://www.rfc-editor.org/info/rfc8065>.   [RFC8066]  Chakrabarti, S., Montenegro, G., Droms, R., and J.              Woodyatt, "IPv6 over Low-Power Wireless Personal Area              Network (6LoWPAN) ESC Dispatch Code Points and              Guidelines", RFC 8066, DOI 10.17487/RFC8066, February              2017, <https://www.rfc-editor.org/info/rfc8066>.   [RFC8138]  Thubert, P., Ed., Bormann, C., Toutain, L., and R. Cragie,              "IPv6 over Low-Power Wireless Personal Area Network              (6LoWPAN) Routing Header", RFC 8138, DOI 10.17487/RFC8138,              April 2017, <https://www.rfc-editor.org/info/rfc8138>.   [RFC8352]  Gomez, C., Kovatsch, M., Tian, H., and Z. Cao, Ed.,              "Energy-Efficient Features of Internet of Things              Protocols", RFC 8352, DOI 10.17487/RFC8352, April 2018,              <https://www.rfc-editor.org/info/rfc8352>.   [RFC8376]  Farrell, S., Ed., "Low-Power Wide Area Network (LPWAN)              Overview", RFC 8376, DOI 10.17487/RFC8376, May 2018,              <https://www.rfc-editor.org/info/rfc8376>.   [RFC8505]  Thubert, P., Ed., Nordmark, E., Chakrabarti, S., and C.              Perkins, "Registration Extensions for IPv6 over Low-Power              Wireless Personal Area Network (6LoWPAN) Neighbor              Discovery", RFC 8505, DOI 10.17487/RFC8505, November 2018,              <https://www.rfc-editor.org/info/rfc8505>.   [RFC8613]  Selander, G., Preuß Mattsson, J., Palombini, F., and L.              Seitz, "Object Security for Constrained RESTful              Environments (OSCORE)", RFC 8613, DOI 10.17487/RFC8613,              July 2019, <https://www.rfc-editor.org/info/rfc8613>.   [RFC8928]  Thubert, P., Ed., Sarikaya, B., Sethi, M., and R. Struik,              "Address-Protected Neighbor Discovery for Low-Power and              Lossy Networks", RFC 8928, DOI 10.17487/RFC8928, November              2020, <https://www.rfc-editor.org/info/rfc8928>.   [RFC8929]  Thubert, P., Ed., Perkins, C.E., and E. Levy-Abegnoli,              "IPv6 Backbone Router", RFC 8929, DOI 10.17487/RFC8929,              November 2020, <https://www.rfc-editor.org/info/rfc8929>.   [RFC9008]  Robles, M.I., Richardson, M., and P. Thubert, "Using RPI              Option Type, Routing Header for Source Routes, and IPv6-              in-IPv6 Encapsulation in the RPL Data Plane", RFC 9008,              DOI 10.17487/RFC9008, April 2021,              <https://www.rfc-editor.org/info/rfc9008>.   [RFC9010]  Thubert, P., Ed. and M. Richardson, "Routing for RPL              (Routing Protocol for Low-Power and Lossy Networks)              Leaves", RFC 9010, DOI 10.17487/RFC9010, April 2021,              <https://www.rfc-editor.org/info/rfc9010>.   [RFC9035]  Thubert, P., Ed. and L. Zhao, "A Routing Protocol for Low-              Power and Lossy Networks (RPL) Destination-Oriented              Directed Acyclic Graph (DODAG) Configuration Option for              the 6LoWPAN Routing Header", RFC 9035,              DOI 10.17487/RFC9035, April 2021,              <https://www.rfc-editor.org/info/rfc9035>.   [RFC9428]  Choi, Y., Ed., Hong, Y., and J. Youn, "Transmission of              IPv6 Packets over Near Field Communication", RFC 9428,              DOI 10.17487/RFC9428, July 2023,              <https://www.rfc-editor.org/info/rfc9428>.   [SEC-PROT-COMP]              Preuß Mattsson, J., Palombini, F., and M. Vučinić,              "Comparison of CoAP Security Protocols", Work in Progress,              Internet-Draft, draft-ietf-iotops-security-protocol-              comparison-02, 11 April 2023,              <https://datatracker.ietf.org/doc/html/draft-ietf-iotops-              security-protocol-comparison-02>.   [Thread]   Thread, "Resources",              <https://www.threadgroup.org/Support>.   [TIA-485-A]              TIA, "Electrical Characteristics of Generators and              Receivers for Use in Balanced Digital Multipoint Systems",              TIA-485-A, Revision of TIA-485, March 1998,              <https://global.ihs.com/              doc_detail.cfm?item_s_key=00032964>.   [TS102.939-1]              ETSI, "Digital Enhanced Cordless Telecommunications              (DECT); Ultra Low Energy (ULE); Machine to Machine              Communications; Part 1: Home Automation Network (phase              1)", V1.2.1, ETSI-TS 102 939-1, March 2015,              <https://www.etsi.org/deliver/              etsi_ts/102900_102999/10293901/01.02.01_60/              ts_10293901v010201p.pdf>.   [TS102.939-2]              ETSI, "Digital Enhanced Cordless Telecommunications              (DECT); Ultra Low Energy (ULE); Machine to Machine              Communications; Part 2: Home Automation Network (phase              2)", V1.1.1, ETSI TS 102 939-2, March 2015,              <https://www.etsi.org/deliver/              etsi_ts/102900_102999/10293902/01.01.01_60/              ts_10293902v010101p.pdf>.   [Wi-SUN]   "Wi-SUN Alliance", <https://www.wi-sun.org>.Appendix A.  Design Space Dimensions for 6lo Deployment   [RFC6568] lists the dimensions used to describe the design space of   wireless sensor networks in the context of the 6LoWPAN Working Group.   The design space is already limited by the unique characteristics of   a LoWPAN (e.g., low power, short range, low bit rate).  In Section 2   of [RFC6568], the following design space dimensions are described:   Deployment, Network Size, Power Source, Connectivity, Multi-Hop   Communication, Traffic Pattern, Mobility, and Quality of Service   (QoS).  However, in this document, the following design space   dimensions are considered:   Deployment/Bootstrapping:      6lo nodes can be connected randomly or in an organized manner.      The bootstrapping has different characteristics for each link-      layer technology.   Topology:      Topology of 6lo networks may inherently follow the characteristics      of each link-layer technology.  Point-to-point, star, tree, or      mesh topologies can be configured, depending on the link-layer      technology considered.   L2-mesh or L3-mesh:      L2-mesh and L3-mesh may inherently follow the characteristics of      each link-layer technology.  Some link-layer technologies may      support L2-mesh and some may not.   Multi-link Subnet and Single Subnet:      The selection of a multi-link subnet and a single subnet depends      on connectivity and the number of 6lo nodes.   Data Rate:      Typically, the link-layer technologies of 6lo have a low rate of      data transmission.  However, by adjusting the MTU, it can deliver      a higher upper-layer data rate.   Buffering Requirements:      Some 6lo use case may require a higher data rate than the link-      layer technology support.  In this case, a buffering mechanism,      telling the application to throttle its generation of data, and      compression of the data are possible to manage the data.   Security and Privacy Requirements:      Some 6lo use cases can involve transferring some important and      personal data between 6lo nodes.  In this case, high-level      security support is required.   Mobility across 6lo Networks and Subnets:      The movement of 6lo nodes depends on the 6lo use case.  If the 6lo      nodes can move or be moved around, a mobility management mechanism      is required.   Time Synchronization Requirements:      The requirement of time synchronization of the upper-layer service      is dependent on the use case.  For some 6lo use cases related to      health service, the measured data must be recorded with the exact      time.   Reliability and QoS:      Some 6lo use cases require high reliability, for example, real-      time or health-related services.   Traffic Patterns:      6lo use cases may involve various traffic patterns.  For example,      some 6lo use cases may require short data lengths and random      transmission.  Some 6lo use cases may require continuous data      transmission and discontinuous data transmission.   Security Bootstrapping:      Without the external operations, 6lo nodes must have a security      bootstrapping mechanism.   Power Use Strategy:      To enable certain use cases, there may be requirements on the      class of energy availability and the strategy followed for using      power for communication [RFC7228].  Each link-layer technology      defines a particular power use strategy that may be tuned      [RFC8352].  Readers are expected to be familiar with the      terminology found in [RFC7228].   Update Firmware Requirements:      Most 6lo use cases will need a mechanism to update firmware.  In      these cases, support for over-the-air updates is required,      probably in a broadcast mode when bandwidth is low and the number      of identical devices is high.   Wired vs. Wireless:      Plenty of 6lo link-layer technologies are wireless, except MS/TP      and PLC.  The selection of wired or wireless link-layer technology      is mainly dependent on the requirements of the 6lo use cases and      the characteristics of wired and wireless technologies.Acknowledgements   Carles Gomez has been funded in part by the Spanish Government   through the Jose Castillejo CAS15/00336 grant, the TEC2016-79988-P   grant, and the PID2019-106808RA-I00 grant as well as by Secretaria   d'Universitats i Recerca del Departament d'Empresa i Coneixement de   la Generalitat de Catalunya through grants 2017 SGR 376 and 2021 SGR   00330.  His contribution to this work has been carried out in part   during his stay as a visiting scholar at the Computer Laboratory of   the University of Cambridge.   Thomas Watteyne, Pascal Thubert, Xavier Vilajosana, Daniel Migault,   Jianqiang Hou, Kerry Lynn, S.V.R. Anand, and Seyed Mahdi Darroudi   have provided valuable feedback for this document.   Das Subir and Michel Veillette have provided valuable information of   jupiterMesh, and Paul Duffy has provided valuable information of Wi-   SUN for this document.  Also, Jianqiang Hou has provided valuable   information of G3-PLC and Netricity for this document.  Take   Aanstoot, Kerry Lynn, and Dave Robin have provided valuable   information of MS/TP and practical use case of MS/TP for this   document.   Deoknyong Ko has provided relevant text of LTE-MTC, and he shared his   experience to deploy IPv6 and 6lo technologies over LTE MTC in SK   Telecom.Authors' Addresses   Yong-Geun Hong   Daejeon University   62 Daehak-ro, Dong-gu   Daejeon   34520   South Korea   Phone: +82 42 280 4841   Email: yonggeun.hong@gmail.com   Carles Gomez   Universitat Politecnica de Catalunya   C/Esteve Terradas, 7   08860 Castelldefels   Spain   Email: carles.gomez@upc.edu   Younghwan Choi   ETRI   218 Gajeongno, Yuseong   Daejeon   34129   South Korea   Phone: +82 42 860 1429   Email: yhc@etri.re.kr   Abdur Rashid Sangi   Wenzhou-Kean University   88 Daxue Road, Ouhai, Wenzhou   Zhejiang   325060   China   Email: sangi_bahrian@yahoo.com   Samita Chakrabarti   Verizon   Bedminster, NJ   United States of America   Email: samita.chakrabarti@verizon.com