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

This html diff was produced by rfcdiff 1.48.