diff options
Diffstat (limited to 'doc/rfc/rfc9453.txt')
| -rw-r--r-- | doc/rfc/rfc9453.txt | 1371 |
1 files changed, 1371 insertions, 0 deletions
diff --git a/doc/rfc/rfc9453.txt b/doc/rfc/rfc9453.txt new file mode 100644 index 0000000..e153e5c --- /dev/null +++ b/doc/rfc/rfc9453.txt @@ -0,0 +1,1371 @@ + + + + +Internet Engineering Task Force (IETF) Y-G. Hong +Request for Comments: 9453 Daejeon University +Category: Informational C. Gomez +ISSN: 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' Addresses + +1. 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 Technologies + +2.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 Technologies + +3. 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 Examples + +4.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. References + +8.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 |