< draft-ietf-6lo-use-cases-09.txt   draft-ietf-6lo-use-cases-10.txt >
6Lo Working Group Y-G. Hong 6Lo Working Group Y-G. Hong
Internet-Draft ETRI Internet-Draft
Intended status: Informational C. Gomez Intended status: Informational C. Gomez
Expires: January 14, 2021 UPC Expires: August 25, 2021 UPC
Y-H. Choi Y-H. Choi
ETRI ETRI
AR. Sangi AR. Sangi
Huaiyin Institute of Technology Huaiyin Institute of Technology
T. Aanstoot
Modio AB
S. Chakrabarti S. Chakrabarti
July 13, 2020 February 21, 2021
IPv6 over Constrained Node Networks (6lo) Applicability & Use cases IPv6 over Constrained Node Networks (6lo) Applicability & Use cases
draft-ietf-6lo-use-cases-09 draft-ietf-6lo-use-cases-10
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 802.15.4, various link layer technologies such as addition to IEEE 802.15.4, various link layer technologies such as
ITU-T G.9959 (Z-Wave), BLE, DECT-ULE, MS/TP, NFC, and PLC (IEEE ITU-T G.9959 (Z-Wave), Bluetooth Low Energy, DECT-ULE, MS/TP, NFC,
1901.2) are used as examples. The document targets an audience who and PLC are used as examples. The document targets an audience who
like to understand and evaluate running end-to-end IPv6 over the would like to understand and evaluate running end-to-end IPv6 over
constrained node networks connecting devices to each other or to the constrained node networks for local or Internet connectivity.
other devices on the Internet (e.g. cloud infrastructure).
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on January 14, 2021. This Internet-Draft will expire on August 25, 2021.
Copyright Notice Copyright Notice
Copyright (c) 2020 IETF Trust and the persons identified as the Copyright (c) 2021 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 Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Conventions and Terminology . . . . . . . . . . . . . . . . . 4 2. 6lo Link layer technologies . . . . . . . . . . . . . . . . . 4
3. 6lo Link layer technologies . . . . . . . . . . . . . . . . . 4 2.1. ITU-T G.9959 . . . . . . . . . . . . . . . . . . . . . . 4
3.1. ITU-T G.9959 . . . . . . . . . . . . . . . . . . . . . . 4 2.2. Bluetooth LE . . . . . . . . . . . . . . . . . . . . . . 4
3.2. Bluetooth LE . . . . . . . . . . . . . . . . . . . . . . 4 2.3. DECT-ULE . . . . . . . . . . . . . . . . . . . . . . . . 5
3.3. DECT-ULE . . . . . . . . . . . . . . . . . . . . . . . . 5 2.4. MS/TP . . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.4. MS/TP . . . . . . . . . . . . . . . . . . . . . . . . . . 5 2.5. NFC . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
3.5. NFC . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 2.6. PLC . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
3.6. PLC . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 2.7. Comparison between 6lo link layer technologies . . . . . 8
3.7. Comparison between 6lo Link layer technologies . . . . . 7 3. Guidelines for adopting IPv6 stack (6lo) . . . . . . . . . . 9
4. 6lo Deployment Scenarios . . . . . . . . . . . . . . . . . . 8 4. 6lo Deployment Scenarios . . . . . . . . . . . . . . . . . . 11
4.1. G3-PLC usage of 6lo in network layer . . . . . . . . . . 8 4.1. Wi-SUN usage of 6lo in network layer . . . . . . . . . . 11
4.2. Netricity usage of 6lo in network layer . . . . . . . . . 9 4.2. Thread usage of 6lo in network layer . . . . . . . . . . 13
5. Guidelines for adopting IPv6 stack (6lo/6LoWPAN) . . . . . . 10 4.3. G3-PLC usage of 6lo in network layer . . . . . . . . . . 13
6. 6lo Use Case Examples . . . . . . . . . . . . . . . . . . . . 12 4.4. Netricity usage of 6lo in network layer . . . . . . . . . 14
6.1. Use case of ITU-T G.9959: Smart Home . . . . . . . . . . 12 5. 6lo Use Case Examples . . . . . . . . . . . . . . . . . . . . 15
6.2. Use case of Bluetooth LE: Smartphone-based Interaction . 13 5.1. Use case of ITU-T G.9959: Smart Home . . . . . . . . . . 15
6.3. Use case of DECT-ULE: Smart Home . . . . . . . . . . . . 14 5.2. Use case of Bluetooth LE: Smartphone-based Interaction . 16
6.4. Use case of MS/TP: Building Automation Networks . . . . . 14 5.3. Use case of DECT-ULE: Smart Home . . . . . . . . . . . . 16
6.5. Use case of NFC: Alternative Secure Transfer . . . . . . 15 5.4. Use case of MS/TP: Building Automation Networks . . . . . 17
6.6. Use case of PLC: Smart Grid . . . . . . . . . . . . . . . 15 5.5. Use case of NFC: Alternative Secure Transfer . . . . . . 18
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 5.6. Use case of PLC: Smart Grid . . . . . . . . . . . . . . . 18
8. Security Considerations . . . . . . . . . . . . . . . . . . . 17 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 17 7. Security Considerations . . . . . . . . . . . . . . . . . . . 19
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 20
10.1. Normative References . . . . . . . . . . . . . . . . . . 17 9. Informative References . . . . . . . . . . . . . . . . . . . 20
10.2. Informative References . . . . . . . . . . . . . . . . . 17 Appendix A. Design Space Dimensions for 6lo Deployment . . . . . 25
Appendix A. Design Space Dimensions for 6lo Deployment . . . . . 22 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 27
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 24
1. Introduction 1. Introduction
Running IPv6 on constrained node networks has different features from Running IPv6 on constrained node networks presents challenges, due to
general node networks due to the characteristics of constrained node the characteristics of these networks such as small packet size, low
networks such as small packet size, short link-layer address, low power, low bandwidth, low cost, and large number of devices, among
bandwidth, network topology, low power, low cost, and large number of others [RFC4919][RFC7228]. For example, many IEEE 802.15.4 variants
devices [RFC4919][RFC7228]. For example, some IEEE 802.15.4 link [IEEE802154] exhibit a frame size of 127 octets, whereas IPv6
layers[IEEE802154] have a frame size of 127 octets and IPv6 requires requires its underlying layer to support an MTU of 1280 bytes.
the layer below to support an MTU of 1280 bytes, therefore an Furthermore, those IEEE 802.15.4 variants do not offer fragmentation
appropriate fragmentation and reassembly adaptation layer must be and reassembly functionality. Therefore, an appropriate adaptation
provided at the layer below IPv6. Also, the limited size of IEEE layer supporting fragmentation and reassembly must be provided below
802.15.4 frame and low energy consumption requirements make the need IPv6. Also, the limited IEEE 802.15.4 frame size and low energy
for header compression. The IETF 6LoPWAN (IPv6 over Low powerWPAN) consumption requirements motivate the need for packet header
working group published an adaptation layer for sending IPv6 packets compression. The IETF IPv6 over Low-Power WPAN (6LoWPAN) working
over IEEE 802.15.4 [RFC4944], which includes a compression format for group published a suite of specification that provide an adaptation
IPv6 datagrams over IEEE 802.15.4-based networks [RFC6282], and layer to support IPv6 over IEEE 802.15.4 comprising the following
Neighbor Discovery Optimization for 6LoPWAN [RFC6775]. functionality:
As IoT (Internet of Things) services become more popular, IPv6 over o Fragmentation and reassembly, address autoconfiguration, and a
various link layer technologies such as Bluetooth Low Energy frame format [RFC4944],
(Bluetooth LE), ITU-T G.9959 (Z-Wave), Digital Enhanced Cordless
o IPv6 (and UDP) header compression [RFC6282],
o Neighbor Discovery Optimization for 6LoWPAN [RFC6775][RFC8505].
As Internet of Things (IoT) services become more popular, the IETF
6lo working group [IETF_6lo] has defined adaptation layer
functionality to support IPv6 over various link layer technologies
other than IEEE 802.15.4, such as Bluetooth Low Energy (Bluetooth
LE), ITU-T G.9959 (Z-Wave), Digital Enhanced Cordless
Telecommunications - Ultra Low Energy (DECT-ULE), Master-Slave/Token Telecommunications - Ultra Low Energy (DECT-ULE), Master-Slave/Token
Passing (MS/TP), Near Field Communication (NFC), and Power Line Passing (MS/TP), Near Field Communication (NFC), and Power Line
Communication (PLC) have been defined at IETF 6lo working Communication (PLC). The 6lo adaptation layers use a variation of
group[IETF_6lo]. IPv6 stacks for constrained node networks use a the 6LoWPAN stack applied to each particular link layer technology.
variation of the 6LoWPAN stack applied to each particular link layer
technology.
In the 6LoPWAN working group, the [RFC6568], "Design and Application The 6LoWPAN working group produced the document entitled "Design and
Spaces for 6LoWPANs" was published and it describes potential Application Spaces for 6LoWPANs" [RFC6568], which describes potential
application scenarios and use cases for low-power wireless personal application scenarios and use cases for low-power wireless personal
area networks. Hence, this 6lo applicability document aims to area networks. The present document aims to provide guidance to an
provide guidance to an audience who are new to IPv6-over-low-power audience who are new to the IPv6 over constrained node networks (6lo)
networks concept and want to assess if variance of 6LoWPAN stack concept and want to assess its application to the constrained node
(6lo) can be applied to the constrained layer two (L2) network of network of their interest. This 6lo applicability document describes
their interest. This 6lo applicability document puts together a few sets of practical 6lo deployment scenarios and use cases
various design space dimensions such as deployment, network size, examples. In addition, it considers various network design space
power source, connectivity, multi-hop communication, traffic pattern, dimensions such as deployment, network size, power source,
security level, mobility, and QoS requirements etc. In addition, it connectivity, multi-hop communication, traffic pattern, security
describes a few set of 6LoPWAN application scenarios and practical level, mobility, and QoS requirements etc.
deployment as examples.
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:
o 6lo applicability and use cases are uniquely different from those o It covers various IoT-related wired/wireless link layer
of 6LoWPAN defined for IEEE 802.15.4.
o It covers various IoT related wire/wireless link layer
technologies providing practical information of such technologies. technologies providing practical information of such technologies.
o A general guideline on how the 6LoWPAN stack can be modified for a o It provides a general guideline on how the 6LoWPAN stack can be
given L2 technology is described. modified for a given L2 technology.
o Various 6lo use cases and practical deployment examples are o Various 6lo use cases and practical deployment examples are
described. described.
2. Conventions and Terminology 2. 6lo Link layer technologies
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
3. 6lo Link layer technologies
3.1. ITU-T G.9959 2.1. ITU-T G.9959
The ITU-T G.9959 Recommendation [G.9959] targets low-power Personal The ITU-T G.9959 Recommendation [G.9959] targets low-power Wireless
Area Networks (PANs), and defines physical layer and link layer Personal Area Networks (WPANs), and defines physical layer and link
functionality. Physical layers of 9.6 kbit/s, 40 kbit/s and 100 layer functionality. Physical layers of 9.6 kbit/s, 40 kbit/s and
kbit/s are supported. G.9959 defines how a unique 32-bit HomeID 100 kbit/s are supported. G.9959 defines how a unique 32-bit HomeID
network identifier is assigned by a network controller and how an network identifier is assigned by a network controller and how an
8-bit NodeID host identifier is allocated to each node. NodeIDs are 8-bit NodeID host identifier is allocated to each node. NodeIDs are
unique within the network identified by the HomeID. The G.9959 unique within the network identified by the HomeID. The G.9959
HomeID represents an IPv6 subnet that is identified by one or more HomeID represents an IPv6 subnet that is identified by one or more
IPv6 prefixes [RFC7428]. The ITU-T G.9959 can be used for smart home IPv6 prefixes [RFC7428]. The ITU-T G.9959 can be used for smart home
applications. applications.
3.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 even further in successive versions. Bluetooth 4.1, and developed further in successive versions. Bluetooth SIG has
SIG has also published Internet Protocol Support Profile (IPSP). The also published the Internet Protocol Support Profile (IPSP). The
IPSP enables discovery of IP-enabled devices and establishment of IPSP enables discovery of IP-enabled devices and establishment of
link-layer connection for transporting IPv6 packets. IPv6 over link-layer connection for transporting IPv6 packets. IPv6 over
Bluetooth LE is dependent on both Bluetooth 4.1 and IPSP 1.0 or Bluetooth LE is dependent on both Bluetooth 4.1 and IPSP 1.0 or
newer. 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 which support Bluetooth 4.0 or subsequent
chipsets 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 such as phones, tablets and notebook collaborate with mobile devices. An example of a use case for a
computers. An example of a use case for a Bluetooth LE accessory is Bluetooth LE accessory is a heart rate monitor that sends data via
a heart rate monitor that sends data via the mobile phone to a server the mobile phone to a server on the Internet [RFC7668]. A typical
on the Internet [RFC7668]. A typical usage of Bluetooth LE is usage of Bluetooth LE is smartphone-based interaction with
smartphone-based interaction with constrained devices. Bluetooth LE constrained devices. Bluetooth LE was originally designed to enable
was originally designed to enable star topology networks. However, star topology networks. However, recent Bluetooth versions support
recent Bluetooth versions support the formation of extended the formation of extended topologies, and IPv6 support for mesh
topologies, and IPv6 support for mesh networks of Bluetooth LE networks of Bluetooth LE devices is being developed
devices is being developed [I-D.ietf-6lo-blemesh] [I-D.ietf-6lo-blemesh]
3.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.
The DECT ULE protocol stack consists of the PHY layer operating at The DECT-ULE protocol stack consists of the physical layer operating
frequencies in the 1880 - 1920 MHz frequency band depending on the at frequencies in the dedicated 1880 - 1920 MHz frequency band
region and uses a symbol rate of 1.152 Mbps. Radio bearers are depending on the region and uses a symbol rate of 1.152 Mbps. Radio
allocated by use of FDMA/TDMA/TDD techniques. bearers are allocated by use of FDMA/TDMA/TDD techniques.
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 MAC layer supports number of Portable Parts (PP) attached. The Medium Access Control
traditional DECT as this is used for services like discovery, (MAC) layer supports traditional DECT as this is used for services
pairing, security features etc. All these features have been reused like discovery, pairing, security features etc. All these features
from DECT. have 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 ULE MAC layer features. The DECT-ULE Data Link
Control (DLC) provides multiplexing as well as segmentation and re- Control (DLC) provides multiplexing as well as segmentation and re-
assembly for larger packets from layers above. The DECT ULE layer assembly for larger packets from layers above. The DECT-ULE layer
also implements per-message authentication and encryption. The DLC also implements per-message authentication and encryption. The DLC
layer ensures packet integrity and preserves packet order, but layer ensures packet integrity and preserves packet order, but
delivery is based on best effort. 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.
3.4. MS/TP 2.4. MS/TP
Master-Slave/Token-Passing (MS/TP) is a Medium Access Control (MAC) MS/TP is a MAC protocol for the RS-485 [TIA-485-A] physical layer and
protocol for the RS-485 [TIA-485-A] physical layer and is used is used primarily in building automation networks.
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: a) MS/TP devices are typically
mains powered, b) all MS/TP devices on a segment can communicate 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) directly so there are no hidden node or mesh routing issues, and c)
the latest MS/TP specification provides support for large payloads, the latest MS/TP specification provides support for large payloads,
eliminating the need for fragmentation and reassembly below IPv6. 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
UART, an RS-485 [TIA-485-A] transceiver with a driver that can be Universal Asynchronous Receiver-Transmitter (UART), an RS-485
disabled, and a 5 ms resolution timer. The MS/TP MAC is typically [TIA-485-A] transceiver with a driver that can be disabled, and a 5
implemented in software. ms resolution timer. The MS/TP MAC is typically implemented in
software.
Because of its superior "range" (~1 km) compared to many low power Because of its superior "range" (~1 km) compared to many low power
wireless data links, MS/TP may be suitable to connect remote devices wireless data links, MS/TP may be suitable to connect remote devices
(such as district heating controllers) to the nearest building (such as district heating controllers) to the nearest building
control infrastructure over a single link [RFC8163]. MS/TP can be control infrastructure over a single link [RFC8163].
used for building automation networks.
3.5. NFC 2.5. NFC
NFC technology enables simple and safe two-way interactions between NFC technology enables simple and safe two-way interactions between
electronic devices, allowing consumers to perform contactless electronic devices, allowing consumers to perform contactless
transactions, access digital content, and connect electronic devices transactions, access digital content, and connect electronic devices
with a single touch. NFC complements many popular consumer level with a single touch. NFC complements many popular consumer level
wireless technologies, by utilizing the key elements in existing wireless technologies, by utilizing the key elements in existing
standards for contactless card technology (ISO/IEC 14443 A&B and standards for contactless card technology (ISO/IEC 14443 A&B and
JIS-X 6319-4). NFC can be compatible with existing contactless card JIS-X 6319-4).
infrastructure and it enables a consumer to utilize one device across
different systems.
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 a
simple touch. simple touch.
NFC's bidirectional communication ability is ideal for establishing NFC's bidirectional communication ability is ideal for establishing
connections with other technologies by the simplicity of touch. In connections with other technologies by the simplicity of touch. In
addition to the easy connection and quick transactions, simple data addition to the easy connection and quick transactions, simple data
sharing is also available [I-D.ietf-6lo-nfc]. NFC can be used for sharing is also available [I-D.ietf-6lo-nfc]. NFC can be used for
secure transfer in healthcare services. secure transfer in healthcare services.
3.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. Unlike other dedicated communication infrastructure, as medium [I-D.ietf-6lo-plc]. Unlike other dedicated communication
power conductors are widely available indoors and outdoors. infrastructure, power conductors are widely available indoors and
Moreover, wired technologies cause less interference to the radio outdoors. Moreover, wired technologies cause less interference to
medium than wireless technologies and are more reliable than their the radio medium than wireless technologies and are more reliable
wireless counterparts. PLC is a data transmission technique that than their wireless counterparts.
utilizes power conductors as medium[I-D.ietf-6lo-plc].
The below table shows some available open standards defining PLC. The below table shows some available open standards defining PLC.
+-------------+-----------------+------------+-----------+----------+ +-------------+-----------------+------------+-----------+----------+
| PLC Systems | Frequency Range | Type | Data Rate | Distance | | PLC Systems | Frequency Range | Type | Data Rate | Distance |
+-------------+-----------------+------------+-----------+----------+ +-------------+-----------------+------------+-----------+----------+
| IEEE1901 | <100MHz | Broadband | 200Mbps | 1000m | | IEEE1901 | <100MHz | Broadband | 200Mbps | 1000m |
| | | | | | | | | | | |
| IEEE1901.1 | <15MHz | PLC-IoT | 10Mbps | 2000m | | IEEE1901.1 | <12MHz | PLC-IoT | 10Mbps | 2000m |
| | | | | | | | | | | |
| IEEE1901.2 | <500kHz | Narrowband | 200Kbps | 3000m | | IEEE1901.2 | <500kHz | Narrowband | 200kbps | 3000m |
| | | | | |
| G3-PLC | <500kHz | Narrowband | 234kbps | 3000m |
+-------------+-----------------+------------+-----------+----------+ +-------------+-----------------+------------+-----------+----------+
Table 1: Some Available Open Standards in PLC Table 1: Some Available Open Standards in PLC
[IEEE1901] defines a broadband variant of PLC but is effective within IEEE 1901 [IEEE1901] defines a broadband variant of PLC but is
short range. This standard addresses the requirements of effective within short range. This standard addresses the
applications with high data rate such as: Internet, HDTV, Audio, requirements of applications with high data rate such as: Internet,
Gaming etc. Broadband operates on OFDM (Orthogonal Frequency HDTV, Audio, Gaming etc. Broadband operates on Orthogonal Frequency
Division Multiplexing) modulation. Division Multiplexing (OFDM) modulation.
[IEEE1901.2] defines a narrowband variant of PLC with less data rate IEEE 1902.1 [IEEE1901.1] defines a medium frequency band (less than
but significantly higher transmission range that could be used in an 12 MHz) broadband PLC technology for smart grid applications based on
indoor or even an outdoor environment. It is applicable to typical OFDM. By achieving an extended communication range with medium
IoT applications such as: Building Automation, Renewable Energy, speeds, this standard can be applied both in indoor and outdoor
Advanced Metering, Street Lighting, Electric Vehicle, Smart Grid etc. scenarios, such as Advanced Metering Infrastructure (AMI), street
Moreover, IEEE 1901.2 standard is based on the 802.15.4 MAC sub-layer lighting, electric vehicle charging, smart city etc.
and fully endorses the security scheme defined in 802.15.4 [RFC8036].
A typical use case of PLC is smart grid.
3.7. Comparison between 6lo Link layer technologies IEEE 1902.2 [IEEE1901.2] defines a narrowband variant of PLC with
less data rate but significantly higher transmission range that could
be used in an indoor or even an outdoor environment. It is
applicable to typical IoT applications such as: Building Automation,
Renewable Energy, Advanced Metering, Street Lighting, Electric
Vehicle, Smart Grid etc. Moreover, IEEE 1901.2 standard is based on
the 802.15.4 MAC sub-layer and fully endorses the security scheme
defined in 802.15.4 [RFC8036]. A typical use case of PLC is smart
grid.
G3-PLC [G3-PLC] is a narrowband PLC technology that is based on the
ITU-T G.9903 Recommendation [G.9903]. The ITU-T G.9903
Recommendation contains the physical layer and data link layer
specification for the G3-PLC narrowband OFDM power line communication
transceivers, for communications via alternating current and direct
current electric power lines over frequencies below 500 kHz.
2.7. Comparison between 6lo link layer technologies
In above clauses, various 6lo link layer technologies are described. In above clauses, various 6lo link layer technologies are described.
The following table shows dominant parameters of each use case The following table shows dominant parameters of each use case
corresponding to the 6lo link layer technology. corresponding to the 6lo link layer technology.
+--------------+---------+---------+---------+---------+---------+---------+ +--------------+---------+---------+---------+---------+---------+---------+
| | Z-Wave | BLE | DECT-ULE| MS/TP | NFC | PLC | | | Z-Wave | BLE | DECT-ULE| MS/TP | NFC | PLC |
+--------------+---------+---------+---------+---------+---------+---------+ +--------------+---------+---------+---------+---------+---------+---------+
| | Home | Interact| | Building| Health- | | | | Home | Interact| | Building| Health- | |
| Usage | Auto- | w/ Smart| Meter | Auto- | care | Smart | | Usage | Auto- | w/ Smart| Meter | Auto- | care | Smart |
skipping to change at page 8, line 36 skipping to change at page 8, line 42
| Requirement | | | | | | | | Requirement | | | | | | |
+--------------+---------+---------+---------+---------+---------+---------+ +--------------+---------+---------+---------+---------+---------+---------+
| Latency, | | | | | | | | Latency, | | | | | | |
| QoS | High | Low | Low | High | High | Low | | QoS | High | Low | Low | High | High | Low |
| Requirement | | | | | | | | Requirement | | | | | | |
+--------------+---------+---------+---------+---------+---------+---------+ +--------------+---------+---------+---------+---------+---------+---------+
| | | | | | | | | | | | | | | |
| Data | Infrequ-| Infrequ-| Infrequ-| Frequent| Small | Infrequ-| | Data | Infrequ-| Infrequ-| Infrequ-| Frequent| Small | Infrequ-|
| Rate | ent | ent | ent | | | ent | | Rate | ent | ent | ent | | | ent |
+--------------+---------+---------+---------+---------+---------+---------+ +--------------+---------+---------+---------+---------+---------+---------+
| RFC # | | | | | draft- | draft- | | RFC # | | RFC7668,| | | draft- | draft- |
| or | RFC7428 | RFC7668 | RFC8105 | RFC8163 | ietf-6lo| ietf-6lo| | or | RFC7428 | ietf-6lo| RFC8105 | RFC8163 | ietf-6lo| ietf-6lo|
| Draft | | | | | -nfc | -plc | | Draft | | -blemesh| | | -nfc | -plc |
+--------------+---------+---------+---------+---------+---------+---------+ +--------------+---------+---------+---------+---------+---------+---------+
Table 2: Comparison between 6lo Link layer technologies Table 2: Comparison between 6lo link layer technologies
3. Guidelines for adopting IPv6 stack (6lo)
6lo aims at reusing and/or adapting existing 6LoWPAN functionality in
order to efficiently support IPv6 over a variety of IoT L2
technologies. The following guideline targets new candidate
constrained L2 technologies that may be considered for running a
modified 6LoWPAN stack on top. The modification of 6LoWPAN stack
should be based on the following:
o Addressing Model: Addressing model determines whether the device
is capable of forming IPv6 link-local and global addresses and
what is the best way to derive the IPv6 addresses for the
constrained L2 devices. L2-address-derived IPv6 addresses are
specified in [RFC4944], but there exist implications for privacy.
For global usage, a unique IPv6 address must be derived using an
assigned prefix and a unique interface ID. [RFC8065] provides
such guidelines. For MAC-derived IPv6 addresses, please refer to
[RFC8163] for IPv6 address mapping examples. Broadcast and
multicast support are dependent on the L2 networks. Most low-
power L2 implementations map multicast to broadcast networks. So
care must be taken in the design when to use broadcast and try to
stick to unicast messaging whenever possible.
o MTU Considerations: The deployment should consider packet maximum
transmission unit (MTU) needs over the link layer and should
consider if fragmentation and reassembly of packets are needed at
the 6LoWPAN layer. For example, if the link layer supports
fragmentation and reassembly of packets, then the 6LoWPAN layer
may not need to support fragmentation/reassembly. In fact, for
most efficiency, choosing a low-power link layer that can carry
unfragmented application packets would be optimum for packet
transmission if the deployment can afford it. Please refer to 6lo
RFCs [RFC7668], [RFC8163], [RFC8105] for example guidance.
o Mesh or L3-Routing: 6LoWPAN specifications provide mechanisms to
support mesh routing at L2, a configuration called mesh-under
[RFC6606]. It is also possible to use an L3 routing protocol in
6LoWPAN, an approach known as route-over. [RFC6550] defines RPL,
a L3 routing protocol for low power and lossy networks using
directed acyclic graphs. 6LoWPAN is routing-protocol-agnostic and
does not specify any particular L2 or L3 routing protocol to use
with a 6LoWPAN stack.
o Address Assignment: 6LoWPAN developed a new version of IPv6
Neighbor Discovery [RFC4861][RFC4862]. 6LoWPAN Neighbor Discovery
[RFC6775][RFC8505] inherits from IPv6 Neighbor Discovery for
mechanisms such as Stateless Address Autoconfiguration (SLAAC) and
Neighbor Unreachability Detection (NUD). A 6LoWPAN node is also
expected to be an IPv6 host per [RFC8200] which means it should
ignore consumed routing headers and Hop-by-Hop options; when
operating in a RPL network [RFC6550], it is also beneficial to
support IP-in-IP encapsulation [I-D.ietf-roll-useofrplinfo]. The
6LoWPAN node should also support [RFC8505] and use it as the
default Neighbor Discovery method. It is the responsibility of
the deployment to ensure unique global IPv6 addresses for Internet
connectivity. For local-only connectivity IPv6 Unique Local
Address (ULA) may be used. [RFC6775][RFC8505] specifies the
6LoWPAN border router (6LBR), which is responsible for prefix
assignment to the 6LoWPAN network. A 6LBR can be connected to the
Internet or to an enterprise network via one of the interfaces.
Please refer to [RFC7668] and [RFC8105] for examples of address
assignment considerations. In addition, privacy considerations
[RFC8065] must be consulted for applicability. In certain
scenarios, the deployment may not support IPv6 address
autoconfiguration due to regulatory and business reasons and may
choose to offer a separate address assignment service. Address
Protection for 6LoWPAN Neighbor Discovery (AP-ND) [RFC8928]
enables Source Address Validation [RFC6620] and protects the
address ownership against impersonation attacks.
o Broadcast Avoidance: 6LoWPAN Neighbor Discovery aims at reducing
the amount of multicast traffic of classical Neighbor Discovery,
since IP-level multicast translates into L2 broadcast in many L2
technologies. 6LoWPAN Neighbor Discovery relies on a proactive
registration to avoid the use of multicast for address resolution.
It also uses a unicast method for Duplicate Address Detection
(DAD), and avoids multicast lookups from all nodes by using non-
onlink prefixes. Router Advertisements (RAs) are also sent in
unicast, in response to Router Solicitations (RSs)
o Host-to-Router interface: 6lo has defined registration extensions
for 6LoWPAN Neighbor Discovery [RFC8505]. This effort provides a
host-to-router interface by which a host can request its router to
ensure reachability for the address registered with the router.
Note that functionality has been developed to ensure that such a
host can benefit from routing services in a RPL network
[I-D.ietf-roll-unaware-leaves]
o Proxy Neighbor Discovery: Further functionality also allows a
device (e.g. an energy-constrained device that needs to sleep most
of the time) to request proxy Neighbor Discovery services from a
6LoWPAN Backbone Router (6BBR) [RFC8505][RFC8929]. The latter
federates a number of links into a multilink subnet.
o Header Compression: IPv6 header compression [RFC6282] is a vital
part of IPv6 over low power communication. Examples of header
compression over different link-layer specifications are found in
[RFC7668], [RFC8163], [RFC8105]. A generic header compression
technique is specified in [RFC7400]. For 6LoWPAN networks where
RPL is the routing protocol, there exist 6LoWPAN header
compression extensions which allow to compress also the RPL
artifacts used when forwarding packets in the route-over mesh
[RFC8138] [I-D.ietf-roll-turnon-rfc8138]
o Security and Encryption: Though 6LoWPAN basic specifications do
not address security at the network layer, the assumption is that
L2 security must be present. In addition, application-level
security is highly desirable. The working groups [IETF_ace] and
[IETF_core] should be consulted for application and transport
level security. 6lo working group is working on address
authentication [RFC8928] and secure bootstrapping is also being
discussed at IETF. However, there may be different levels of
security available in a deployment through other standards such as
hardware-level security or certificates for initial booting
process. Encryption is important if the implementation can afford
it.
o Additional processing: [RFC8066] defines guidelines for ESC
dispatch octets use in the 6LoWPAN header. An implementation may
take advantage of ESC header to offer a deployment specific
processing of 6LoWPAN packets.
4. 6lo Deployment Scenarios 4. 6lo Deployment Scenarios
4.1. G3-PLC usage of 6lo in network layer 4.1. Wi-SUN usage of 6lo in network layer
G3-PLC [G3-PLC] is a narrow-band PLC technology that is based on Wireless Smart Ubiquitous Network (Wi-SUN)[Wi-SUN] is a technology
ITU-T G.9903 Recommendation [G.9903]. G3-PLC supports multi-hop mesh based on the IEEE 802.15.4g standard. Wi-SUN networks support star
network, and facilitates highly-reliable, long-range communication. and mesh topologies, as well as hybrid star/mesh deployments, but
With the abilities to support IPv6 and to cross transformers, G3-PLC these are typically laid out in a mesh topology where each node
is regarded as one of the next-generation NB-PLC technologies. relays data for the network to provide network connectivity. Wi-SUN
networks are deployed on both powered and battery-operated devices
[RFC8376].
G3-PLC has got massive deployments over several countries, e.g. The main application domains targeted by Wi-SUN are smart utility and
Japan and France. smart city networks. This includes, but is not limited to the
following applications:
o Advanced Metering Infrastructure
o Distribution Automation
o Home Energy Management
o Infrastructure Management
o Intelligent Transportation Systems
o Smart Street Lighting
o Agriculture
o Structural health (bridges, buildings)
o Monitoring and Asset Management
o Smart Thermostats, Air Conditioning and Heat Controls
o Energy Usage Information Displays
The Wi-SUN Alliance Field Area Network (FAN) covers primarily outdoor
networks, and its specification is oriented towards meeting the more
rigorous challenges of these environments. It has the following
features:
o Open standards based on IEEE802, IETF, TIA, ETSI
o Architecture based on an IPv6 frequency hopping wireless mesh
network with enterprise-level security
o Simple infrastructure of low cost, low complexity
o Enhanced network robustness, reliability, and resilience to
interference, due to high redundancy and frequency hopping
o Enhanced scalability, long range, and energy friendliness
o Supports multiple global license-exempt sub-GHz bands
o Multi-vendor interoperability
o Very low power modes in development permitting long term battery
operation of network nodes
The Wi-SUN FAN specification defines an IPv6-based protocol suite
including TCP/UDP, IPv6, 6lo adaptation layer, DHCPv6 for IPv6
address management, RPL, and ICMPv6.
4.2. Thread usage of 6lo in network layer
Thread is an IPv6-based networking protocol stack built on open
standards, designed for smart home environments, and based on low-
power IEEE 802.15.4 mesh networks. Because of its IPv6 foundation,
Thread can support existing popular application layers and IoT
platforms, provide end-to-end security, ease development and enable
flexible and future-proof designs [Thread].
The Thread specification uses the IEEE 802.15.4 [IEEE802154] physical
and MAC layers operating at 250 kbps in the 2.4 GHz band. The IEEE
802.15.4-2006 and IEEE 802.15.4-2015 versions of the specification
are used by Thread.
Thread devices use 6LoWPAN, as defined in [RFC4944][RFC6282], for
transmission of IPv6 Packets over IEEE 802.15.4 networks. Header
compression is used within the Thread network and devices
transmitting messages compress the IPv6 header to minimize the size
of the transmitted packet. The mesh header is supported for link-
layer (i.e., mesh under) forwarding. The mesh header as used in
Thread also allows efficient end-to-end fragmentation of messages
rather than the hop-by-hop fragmentation specified in [RFC4944].
Mesh under routing in Thread is based on a distance vector protocol
in a full mesh topology.
4.3. G3-PLC usage of 6lo in network layer
G3-PLC [G3-PLC] is a narrowband PLC technology that is based on the
ITU-T G.9903 Recommendation [G.9903]. G3-PLC supports multi-hop mesh
network topology, and facilitates highly-reliable, long-range
communication. With the abilities to support IPv6 and to cross
transformers, G3-PLC is regarded as one of the next-generation
narrowband PLC technologies. G3-PLC has got massive deployments over
several countries, e.g. Japan and France.
The main application domains targeted by G3-PLC are smart grid and The main application domains targeted by G3-PLC are smart grid and
smart cities. This includes, but is not limited to the following smart cities. This includes, but is not limited to the following
applications: applications:
o Smart Metering o Smart Metering
o Vehicle-to-Grid Communication o Vehicle-to-Grid Communication
o Demand Response (DR) o Demand Response
o Distribution Automation o Distribution Automation
o Home/Building Energy Management Systems o Home/Building Energy Management Systems
o Smart Street Lighting o Smart Street Lighting
o Advanced Metering Infrastructure (AMI) backbone network o Advanced Metering Infrastructure (AMI) backbone network
o Wind/Solar Farm Monitoring o 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[I-D.ietf-6lo-plc]. The ESC dispatch type is used in the requirements [I-D.ietf-6lo-plc]. The ESC dispatch type is used in
G3-PLC to provide native mesh routing and bootstrapping the G3-PLC to provide native mesh routing and bootstrapping
functionalities[RFC8066]. functionalities [RFC8066].
4.2. Netricity usage of 6lo in network layer 4.4. Netricity usage of 6lo in network layer
The Netricity program in HomePlug Powerline Alliance [NETRICITY] The Netricity program in HomePlug Powerline Alliance [NETRICITY]
promotes the adoption of products built on the IEEE 1901.2 Low- promotes the adoption of products built on the IEEE 1901.2 low-
Frequency Narrow-Band PLC standard, which provides for urban and long frequency narrowband PLC standard, which provides for urban and long
distance communications and propagation through transformers of the distance communications and propagation through transformers of the
distribution network using frequencies below 500 kHz. The technology distribution network using frequencies below 500 kHz. The technology
also addresses requirements that assure communication privacy and also addresses requirements that assure communication privacy and
secure networks. secure networks.
The main application domains targeted by Netricity are smart grid and The main application domains targeted by Netricity are smart grid and
smart cities. This includes, but is not limited to the following smart cities. This includes, but is not limited to the following
applications: applications:
o Utility grid modernization o Utility grid modernization
skipping to change at page 10, line 4 skipping to change at page 14, line 35
also addresses requirements that assure communication privacy and also addresses requirements that assure communication privacy and
secure networks. secure networks.
The main application domains targeted by Netricity are smart grid and The main application domains targeted by Netricity are smart grid and
smart cities. This includes, but is not limited to the following smart cities. This includes, but is not limited to the following
applications: applications:
o Utility grid modernization o Utility grid modernization
o Distribution automation o Distribution automation
o Meter-to-Grid connectivity o Meter-to-Grid connectivity
o Micro-grids o Micro-grids
o Grid sensor communications o Grid sensor communications
o Load control o Load control
o Demand response o Demand response
o Net metering o Net metering
o Street Lighting control o Street Lighting control
o Photovoltaic panel monitoring o Photovoltaic panel monitoring
Netricity system architecture is based on the physical and MAC layers
Netricity system architecture is based on the PHY and MAC layers of of IEEE 1901.2 PLC standard. Regarding the 6lo adaptation layer and
IEEE 1901.2 PLC standard. Regarding the 6lo adaptation layer and
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 layer 3 routing in Netricity uses RPL in non-storing mode that the L3 routing in Netricity uses RPL in non-storing mode with
with the MRHOF objective function based on the own defined Estimated the MRHOF objective function based on the own defined Estimated
Transmission Time (ETT) metric. Transmission Time (ETT) metric.
5. Guidelines for adopting IPv6 stack (6lo/6LoWPAN) 5. 6lo Use Case Examples
The following guideline targets new candidate constrained L2
technologies that may be considered for running modified 6LoWPAN
stack on top. The modification of 6LoWPAN stack SHOULD be based on
the following:
o Addressing Model: Addressing model determines whether the device
is capable of forming IPv6 Link-local and global addresses and
what is the best way to derive the IPv6 addresses for the
constrained L2 devices. Whether the device is capable of forming
IPv6 Link-local and global addresses, L2-address-derived IPv6
addresses are specified in [RFC4944], but there exist implications
for privacy. For global usage, a unique IPv6 address must be
derived using an assigned prefix and a unique interface ID.
[RFC8065] provides such guidelines. For MAC derived IPv6 address,
please refer to [RFC8163] for IPv6 address mapping examples.
Broadcast and multicast support are dependent on the L2 networks.
Most low-power L2 implementations map multicast to broadcast
networks. So care must be taken in the design when to use
broadcast and try to stick to unicast messaging whenever possible.
o MTU Considerations: The deployment SHOULD consider their need for
maximum transmission unit (MTU) of a packet over the link layer
and SHOULD consider if fragmentation and reassembly of packets are
needed at the 6LoWPAN layer. For example, if the link layer
supports fragmentation and reassembly of packets, then 6LoWPAN
layer may skip supporting fragmentation/reassembly. In fact, for
most efficiency, choosing a low-power link layer that can carry
unfragmented application packets would be optimum for packet
transmission if the deployment can afford it. Please refer to 6lo
RFCs [RFC7668], [RFC8163], [RFC8105] for example guidance.
o Mesh or L3-Routing: 6LoWPAN specifications do provide mechanisms
to support for mesh routing at L2. [RFC6550] defines layer three
(L3) routing for low power lossy networks using directed graphs.
6LoWPAN is routing protocol agnostic and other L2 or L3 routing
protocols can be run using a 6LoWPAN stack.
o Address Assignment: 6LoWPAN developed a new version of IPv6
Neighbor Discovery[RFC4861][RFC4862] that relies on a proactive
registration to avoid the use of multicast. 6LoWPAN Neighbor
Discovery[RFC6775][RFC8505] inherits from IPv6 Neighbor Discovery
for mechanisms such as Stateless Address Autoconfiguration(SLAAC)
and Neighbor Unreachability Detection(NUD), but uses a unicast
method for Duplicate Address Detection(DAD), and avoids multicast
lookups from all nodes by using non-onlink prefixes. A 6LoWPAN
Node is also expected to be an IPv6 host per[RFC8200] which means
it should ignore consumed routing headers and Hop-by-Hop options;
when operating in a RPL network[RFC6550], it is also beneficial to
support IP-in-IP encapsulation [I-D.ietf-roll-useofrplinfo]. The
6LoWPWAN Node should also support [RFC8505] and use it as the
default Neighbor Discovery method. It is the responsibility of
the deployment to ensure unique global IPv6 addresses for the
Internet connectivity. For local-only connectivity IPv6 ULA may
be used. [RFC6775] specifies the 6LoWPAN border router(6LBR)
which is responsible for prefix assignment to the 6lo/6LoWPAN
network. 6LBR can be connected to the Internet or Enterprise
network via its one of the interfaces. Please refer to [RFC7668]
and [RFC8105] for examples of address assignment considerations.
In addition, privacy considerations [RFC8065] must be consulted
for applicability. In certain scenarios, the deployment may not
support autoconfiguration of IPv6 addressing due to regulatory and
business reasons and may choose to offer a separate address
assignment service.
o Header Compression: IPv6 header compression [RFC6282] is a vital
part of IPv6 over low power communication. Examples of header
compression for different link-layers specifications are found in
[RFC7668], [RFC8163], [RFC8105]. A generic header compression
technique is specified in [RFC7400].
o Security and Encryption: Though 6LoWPAN basic specifications do
not address security at the network layer, the assumption is that
L2 security must be present. In addition, application level
security is highly desirable. The working groups [IETF_ace] and
[IETF_core] should be consulted for application and transport
level security. 6lo working group is working on address
authentication [I-D.ietf-6lo-ap-nd] and secure bootstrapping is
also being discussed at IETF. However, there may be different
levels of security available in a deployment through other
standards such as hardware level security or certificates for
initial booting process. Encryption is important if the
implementation can afford it.
o Additional processing: [RFC8066] defines guidelines for ESC
dispatch octets use in the 6LoWPAN header. An implementation may
take advantage of ESC header to offer a deployment specific
processing of 6LoWPAN packets.
6. 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 clause, various 6lo various 6lo use cases can be provided. In this section, various 6lo
use cases which are based on each particular link layer technology use cases which are based on different link layer technologies are
are described. described.
6.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.
Example: Use of ITU-T G.9959 for Home Automation Example: Use of ITU-T G.9959 for Home Automation
Variety of home devices (e.g. light dimmers/switches, plugs, Variety of home devices (e.g. light dimmers/switches, plugs,
skipping to change at page 13, line 15 skipping to change at page 15, line 50
sensor may send an alarm message to a safety system). 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 multihop paradigm
allows end-to-end connectivity when direct range communication is not allows end-to-end connectivity when direct range communication is not
possible. Security support is required, specially for safety-related possible. Security support is required, specially for safety-related
communication. When a user interaction (e.g. a button press) communication. When a user interaction (e.g. a button press)
triggers a message that encapsulates a command, if the message is triggers a message that encapsulates a command, if the message is
lost, the user may have to perform further interactions to achieve lost, the user may have to perform further interactions to achieve
the desired effect (e.g. a light is turned off). A reaction to a the desired effect (e.g. turning off a light). A reaction to a user
user interaction will be perceived by the user as immediate as long interaction will be perceived by the user as immediate as long as the
as the reaction takes place within 0.5 seconds [RFC5826]. reaction takes place within 0.5 seconds [RFC5826].
6.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 the interaction between the 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 4G, the smartphone can act as a Internet access, such as Wi-Fi or 4G, the smartphone can act as 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,
skipping to change at page 13, line 41 skipping to change at page 16, line 29
Example: Use of Bluetooth LE-based Body Area Network for fitness Example: Use of Bluetooth LE-based Body Area Network for fitness
A person wears a smartwatch for fitness purposes. The smartwatch has A person wears a smartwatch for fitness purposes. The smartwatch has
several sensors (e.g. heart rate, accelerometer, gyrometer, GPS, several sensors (e.g. heart rate, accelerometer, gyrometer, GPS,
temperature, etc.), a display, and a Bluetooth LE radio interface. temperature, etc.), a display, and a Bluetooth LE radio interface.
The smartwatch can show fitness-related statistics on its display. The smartwatch can show fitness-related statistics on its display.
However, when a paired smartphone is in the range of the smartwatch, However, when a paired smartphone is in the range of the smartwatch,
the latter can report almost real-time measurements of its sensors to the latter can report almost real-time measurements of its sensors to
the smartphone, which can forward the data to a cloud service on the the smartphone, which can forward the data to a cloud service on the
Internet. In addition, the smartwatch can receive notifications Internet. 6lo enables this use case by providing efficient end-to-end
IPv6 support. In addition, the smartwatch can receive notifications
(e.g. alarm signals) from the cloud service via the smartphone. On (e.g. alarm signals) from the cloud service via the smartphone. On
the other hand, the smartphone may locally generate messages for the the other hand, the smartphone may locally generate messages for the
smartwatch, such as e-mail reception or calendar notifications. 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 is
the central component. Support for extended network topologies (e.g. the central component. Support for extended network topologies (e.g.
mesh networks) is being developed as of the writing. mesh networks) is being developed as of the writing.
6.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, a device that
typically acts as a base station for wireless telephones. Therefore, typically acts as a base station for wireless telephones. Therefore,
DECT-ULE is specially suitable for the connected home space in DECT-ULE is specially suitable for the connected home space in
application areas such as home automation, smart metering, safety, application areas such as home automation, smart metering, safety,
healthcare, etc. healthcare, etc. Since DECT-ULE uses dedicated bandwidth, it avoids
the coexistence issues suffered by other technologies that use e.g.
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 Fixed Part
of the home. The Fixed Part can act as a router connected to the of the home. The Fixed Part can act as a router connected to the
Internet. This way, the smart meter can transmit electricity Internet. This way, the smart meter can transmit electricity
consumption readings through the DECT-ULE link with the Fixed Part, consumption readings through the DECT-ULE link with the Fixed Part,
and the latter can forward such readings to the utility company using and the latter can forward such readings to the utility company using
Wide Area Network (WAN) links. The meter can also receive queries Wide Area Network (WAN) links. The meter can also receive queries
from the utility company or from an advanced energy control system from the 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 Fixed Part
via DECT-ULE. via DECT-ULE.
6.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 inter-connect the most numerous elements (sensors and actuators) to inter-connect 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 of 6LoBAC is that it is designed to co-exist with BACnet MS/TP on the
same link, easing the ultimate transition of some BACnet networks to same link, easing the ultimate transition of some BACnet networks to
native end-to-end IPv6 transport protocols. New applications for native end-to-end IPv6 transport protocols. New applications for
6LoBAC may be found in other domains where low cost, long distance, 6LoBAC may be found in other domains where low cost, long distance,
and low latency are required. and low latency are required. Note that BACnet comprises various
networking solutions other than MS/TP, including the recently emerged
BACnet IP. However, the latter is based on high speed Ethernet
infrastructure, and thus it falls outside of the constrained node
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 may
connect to HVAC or other controls such as lighting or blinds. The connect to HVAC or other controls such as lighting or blinds. The
economics of daisy-chaining a single twisted-pair between multiple economics of daisy-chaining a single twisted-pair between multiple
devices is often preferred over home-run Cat-5 style wiring. 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 traditional Ethernet link and several 6LoBAC links, fanning out to a traditional 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-site other wired technologies such as DSL, and 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.
6.5. Use case of NFC: Alternative Secure Transfer 5.5. Use case of NFC: Alternative Secure Transfer
According to applications, various secured data can be handled and In different applications, a variety of secured data can be handled
transferred. Depending on security level of the data, methods for and transferred. Depending on the security level of the data,
transfer 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 A senior citizen who lives alone wears one to several wearable 6lo
devices to measure heartbeat, pulse rate, etc. The 6lo devices are devices to measure heartbeat, pulse rate, etc. The 6lo devices are
densely installed at home for movement detection. An LoWPAN Border densely installed at home for movement detection. A 6LBR at home
Router (LBR) at home will send the sensed information to a connected will send the sensed information to a connected healthcare center.
healthcare center. Portable base stations with LCDs may be used to Portable base stations with LCDs may be used to check the data at
check the data at home, as well. Data is gathered in both periodic home, as well. Data is gathered in both periodic and event-driven
and event-driven fashion. In this application, event-driven data can fashion. In this application, event-driven data can be very time-
be very time-critical. In addition, privacy also becomes a serious critical. In addition, privacy also becomes a serious issue in this
issue in this case, as the sensed data is very personal. case, as the sensed data is very personal.
While the senior citizen is provided audio and video healthcare While the senior citizen is provided audio and video healthcare
services by a tele-assistance based on LTE connections, the senior services by a tele-assistance based on LTE connections, the senior
citizen can alternatively use NFC connections to transfer the citizen can alternatively use NFC connections to transfer the
personal sensed data to the tele-assistance. At this moment, hidden personal sensed data to the tele-assistance. Hidden hackers can
hackers can overhear the data based on the LTE connection, but they overhear the data based on the LTE connection, but they cannot gather
cannot gather the personal data over the NFC connection. the personal data over the NFC connection.
6.6. Use case of PLC: Smart Grid 5.6. Use case of PLC: Smart Grid
Smart grid concept is based on numerous operational and energy The smart grid concept is based on deploying numerous operational and
measuring sub-systems of an electric grid. It comprises of multiple energy measuring sub-systems in an electricity grid system. It
administrative levels/segments to provide connectivity among these comprises multiple administrative levels/segments to provide
numerous components. Last mile connectivity is established over LV connectivity among these numerous components. Last mile connectivity
segment, whereas connectivity over electricity distribution takes is established over the Low Voltage (LV) segment, whereas
place in HV segment. connectivity over electricity distribution takes place in the High
Voltage (HV) segment. Smart grid systems include Advanced Metering
Infrastructure (AMI), Demand Response (DR), Home Energy Management
System (HEMS), Wide Area Situational Awareness (WASA), among others.
Although other wired and wireless technologies are also used in Smart Although other wired and wireless technologies are also used in Smart
Grid (Advance Metering Infrastructure - AMI, Demand Response - DR, Grid, PLC enjoys the advantage of reliable data communication over
Home Energy Management System - HEMS, Wide Area Situational Awareness electrical power lines that are already present, and the deployment
- WASA etc), PLC enjoys the advantage of existing (power conductor) cost can be comparable to wireless technologies. The 6lo-related
medium and better reliable data communication. PLC is a promising scenarios for PLC mainly lie in the LV PLC networks with most
wired communication technology in that the electrical power lines are applications in the area of Advanced Metering Infrastructure,
already there and the deployment cost can be comparable to wireless Vehicle-to-Grid communications, in-home energy management and smart
technologies. The 6lo related scenarios lie in the low voltage PLC street lighting.
networks with most applications in the area of Advanced Metering
Infrastructure, Vehicle-to-Grid communications, in-home energy
management and smart street lighting.
Example: Use of PLC for Advanced Metering Infrastructure Example: Use of PLC for Advanced Metering Infrastructure
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 to
the Meter Data Management System (MDMS) through WAN network (e.g. the Meter Data Management System (MDMS) through WAN network (e.g.
Medium-Voltage PLC, Ethernet or GPRS) for storage and analysis. Two- Medium-Voltage PLC, Ethernet or GPRS) for storage and analysis. Two-
way communications are enabled which means smart meters can do way communications are enabled which means smart meters can do
actions like notification of electricity charges according to the actions like notification of electricity charges according to the
skipping to change at page 16, line 38 skipping to change at page 19, line 31
With the existing power line infrastructure as communication medium, With the existing power line infrastructure as communication medium,
cost on building up the PLC network is naturally saved, and more cost on building up the PLC network is naturally saved, and more
importantly, labor operational costs can be minimized from a long- importantly, labor operational costs can be minimized from a long-
term perspective. Furthermore, this AMI application speeds up term perspective. Furthermore, this AMI application speeds up
electricity charge, reduces losses by restraining power theft and electricity charge, reduces losses by restraining power theft and
helps to manage the health of the grid based on line loss analysis. helps to manage the health of the grid based on line loss analysis.
Example: Use of PLC (IEEE1901.1) for WASA in Smart Grid Example: Use of PLC (IEEE1901.1) for WASA in Smart Grid
Many sub-systems of Smart Grid require low data rate and narrowband Many sub-systems of Smart Grid require low data rate and narrowband
variant (IEEE1901.2) of PLC fulfils such requirements. Recently, variants (e.g., IEEE1901.1) of PLC fulfill such requirements.
more complex scenarios are emerging that require higher data rates. Recently, more complex scenarios are emerging that require higher
data rates.
WASA sub-system is an appropriate example that collects large amount WASA sub-system is an appropriate example that collects large amount
of information about the current state of the grid over wide area of information about the current state of the grid over wide area
from electric substations as well as power transmission lines. The from electric substations as well as power transmission lines. The
collected feedback is used for monitoring, controlling and protecting collected feedback is used for monitoring, controlling and protecting
all the sub-systems. all the sub-systems.
7. IANA Considerations 6. IANA Considerations
There are no IANA considerations related to this document. There are no IANA considerations related to this document.
8. Security Considerations 7. Security Considerations
Security considerations are not directly applicable to this document. Security considerations are not directly applicable to this document.
The use cases will use the security requirements described in the For the use cases, the security requirements described in the
protocol specifications. protocol specifications apply.
9. Acknowledgements 8. Acknowledgements
Carles Gomez has been funded in part by the Spanish Government Carles Gomez has been funded in part by the Spanish Government
through the Jose Castillejo CAS15/00336 grant, and through the through the Jose Castillejo CAS15/00336 grant, the TEC2016-79988-P
TEC2016-79988-P grant. His contribution to this work has been grant, and the PID2019-106808RA-I00 grant, and by Secretaria
carried out in part during his stay as a visiting scholar at the d'Universitats i Recerca del Departament d'Empresa i Coneixement de
Computer Laboratory of the University of Cambridge. 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, Thomas Watteyne, Pascal Thubert, Xavier Vilajosana, Daniel Migault,
and Jianqiang HOU have provided valuable feedback for this draft. 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 Das Subir and Michel Veillette have provided valuable information of
jupiterMesh and Paul Duffy has provided valuable information of Wi- jupiterMesh and Paul Duffy has provided valuable information of Wi-
SUN for this draft. Also, Jianqiang Hou has provided valuable SUN for this draft. Also, Jianqiang Hou has provided valuable
information of G3-PLC and Netricity for this draft. Kerry Lynn and information of G3-PLC and Netricity for this draft. Take Aanstoot,
Dave Robin have provided valuable information of MS/TP and practical Kerry Lynn, and Dave Robin have provided valuable information of MS/
use case of MS/TP for this draft. TP and practical use case of MS/TP for this draft.
Deoknyong Ko has provided relevant text of LTE-MTC and he shared his 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 experience to deploy IPv6 and 6lo technologies over LTE MTC in SK
Telecom. Telecom.
10. References 9. Informative References
10.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
10.2. Informative References
[BACnet] "ASHRAE, "BACnet-A Data Communication Protocol for [BACnet] "ASHRAE, "BACnet-A Data Communication Protocol for
Building Automation and Control Networks", ANSI/ASHRAE Building Automation and Control Networks", ANSI/ASHRAE
Standard 135-2016", January 2016, Standard 135-2016", January 2016,
<http://www.techstreet.com/ashrae/standards/ashrae- <http://www.techstreet.com/ashrae/standards/ashrae-
135-2016?product_id=1918140#jumps>. 135-2016?product_id=1918140#jumps>.
[G.9903] "International Telecommunication Union, "Narrowband [G.9903] "International Telecommunication Union, "Narrowband
orthogonal frequency division multiplexing power line orthogonal frequency division multiplexing power line
communication transceivers for G3-PLC networks", ITU-T communication transceivers for G3-PLC networks", ITU-T
skipping to change at page 18, line 24 skipping to change at page 21, line 12
[G3-PLC] "G3-PLC Alliance", <http://www.g3-plc.com/home/>. [G3-PLC] "G3-PLC Alliance", <http://www.g3-plc.com/home/>.
[IEEE1901] [IEEE1901]
"IEEE Standard, IEEE Std. 1901-2010 - IEEE Standard for "IEEE Standard, IEEE Std. 1901-2010 - IEEE Standard for
Broadband over Power Line Networks: Medium Access Control Broadband over Power Line Networks: Medium Access Control
and Physical Layer Specifications", 2010, and Physical Layer Specifications", 2010,
<https://standards.ieee.org/findstds/ <https://standards.ieee.org/findstds/
standard/1901-2010.html>. standard/1901-2010.html>.
[IEEE1901.1]
"IEEE Standard, IEEE Std. 1901.1-2018 - IEEE Standard for
Medium Frequency (less than 12 MHz) Power Line
Communications for Smart Grid Applications", 2018,
<https://ieeexplore.ieee.org/document/8360785>.
[IEEE1901.2] [IEEE1901.2]
"IEEE Standard, IEEE Std. 1901.2-2013 - IEEE Standard for "IEEE Standard, IEEE Std. 1901.2-2013 - IEEE Standard for
Low-Frequency (less than 500 kHz) Narrowband Power Line Low-Frequency (less than 500 kHz) Narrowband Power Line
Communications for Smart Grid Applications", 2013, Communications for Smart Grid Applications", 2013,
<https://standards.ieee.org/findstds/ <https://standards.ieee.org/findstds/
standard/1901.2-2013.html>. standard/1901.2-2013.html>.
[IEEE802154] [IEEE802154]
IEEE standard for Information Technology, "IEEE Std. IEEE standard for Information Technology, "IEEE Std.
802.15.4, Part. 15.4: Wireless Medium Access Control (MAC) 802.15.4, Part. 15.4: Wireless Medium Access Control (MAC)
and Physical Layer (PHY) Specifications for Low-Rate and Physical Layer (PHY) Specifications for Low-Rate
Wireless Personal Area Networks". Wireless Personal Area Networks".
[I-D.ietf-6lo-ap-nd]
Thubert, P., Sarikaya, B., Sethi, M., and R. Struik,
"Address Protected Neighbor Discovery for Low-power and
Lossy Networks", draft-ietf-6lo-ap-nd-23 (work in
progress), April 2020.
[I-D.ietf-6lo-blemesh] [I-D.ietf-6lo-blemesh]
Gomez, C., Darroudi, S., Savolainen, T., and M. Spoerk, Gomez, C., Darroudi, S., Savolainen, T., and M. Spoerk,
"IPv6 Mesh over BLUETOOTH(R) Low Energy using IPSP", "IPv6 Mesh over BLUETOOTH(R) Low Energy using IPSP",
draft-ietf-6lo-blemesh-07 (work in progress), December draft-ietf-6lo-blemesh-09 (work in progress), December
2019. 2020.
[I-D.ietf-6lo-nfc] [I-D.ietf-6lo-nfc]
Choi, Y., Hong, Y., Youn, J., Kim, D., and J. Choi, Choi, Y., Hong, Y., Youn, J., Kim, D., and J. Choi,
"Transmission of IPv6 Packets over Near Field "Transmission of IPv6 Packets over Near Field
Communication", draft-ietf-6lo-nfc-16 (work in progress), Communication", draft-ietf-6lo-nfc-17 (work in progress),
July 2020. August 2020.
[I-D.ietf-6lo-plc] [I-D.ietf-6lo-plc]
Hou, J., Liu, B., Hong, Y., Tang, X., and C. Perkins, Hou, J., Liu, B., Hong, Y., Tang, X., and C. Perkins,
"Transmission of IPv6 Packets over PLC Networks", draft- "Transmission of IPv6 Packets over PLC Networks", draft-
ietf-6lo-plc-04 (work in progress), June 2020. ietf-6lo-plc-05 (work in progress), October 2020.
[I-D.ietf-roll-useofrplinfo] [I-D.ietf-roll-useofrplinfo]
Robles, I., Richardson, M., and P. Thubert, "Using RPI Robles, I., Richardson, M., and P. Thubert, "Using RPI
Option Type, Routing Header for Source Routes and IPv6-in- Option Type, Routing Header for Source Routes and IPv6-in-
IPv6 encapsulation in the RPL Data Plane", draft-ietf- IPv6 encapsulation in the RPL Data Plane", draft-ietf-
roll-useofrplinfo-40 (work in progress), June 2020. roll-useofrplinfo-44 (work in progress), January 2021.
[I-D.ietf-roll-unaware-leaves]
Thubert, P. and M. Richardson, "Routing for RPL Leaves",
draft-ietf-roll-unaware-leaves-30 (work in progress),
January 2021.
[I-D.ietf-roll-turnon-rfc8138]
Thubert, P. and L. Zhao, "A RPL DODAG Configuration Option
for the 6LoWPAN Routing Header", draft-ietf-roll-turnon-
rfc8138-18 (work in progress), December 2020.
[IETF_6lo] [IETF_6lo]
"IETF IPv6 over Networks of Resource-constrained Nodes "IETF IPv6 over Networks of Resource-constrained Nodes
(6lo) working group", (6lo) working group",
<https://datatracker.ietf.org/wg/6lo/charter/>. <https://datatracker.ietf.org/wg/6lo/charter/>.
[IETF_ace] [IETF_ace]
"IETF Authentication and Authorization for Constrained "IETF Authentication and Authorization for Constrained
Environments (ace) working group", Environments (ace) working group",
<https://datatracker.ietf.org/wg/ace/charter/>. <https://datatracker.ietf.org/wg/ace/charter/>.
[IETF_core] [IETF_core]
"IETF Constrained RESTful Environments (core) working "IETF Constrained RESTful Environments (core) working
group", <https://datatracker.ietf.org/wg/core/charter/>. group", <https://datatracker.ietf.org/wg/core/charter/>.
[Wi-SUN] "Wi-SUN Alliance", <http://www.wi-sun.org>.
[Thread] "Thread Group", <https://www.threadgroup.org/Support>.
[NETRICITY] [NETRICITY]
"Netricity program in HomePlug Powerline Alliance", "Netricity program in HomePlug Powerline Alliance",
<http://groups.homeplug.org/tech/Netricity>. <http://groups.homeplug.org/tech/Netricity>.
[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
skipping to change at page 20, line 39 skipping to change at page 23, line 33
Low-Power and Lossy Networks", RFC 6550, Low-Power and Lossy Networks", RFC 6550,
DOI 10.17487/RFC6550, March 2012, DOI 10.17487/RFC6550, March 2012,
<https://www.rfc-editor.org/info/rfc6550>. <https://www.rfc-editor.org/info/rfc6550>.
[RFC6568] Kim, E., Kaspar, D., and JP. Vasseur, "Design and [RFC6568] Kim, E., Kaspar, D., and JP. Vasseur, "Design and
Application Spaces for IPv6 over Low-Power Wireless Application Spaces for IPv6 over Low-Power Wireless
Personal Area Networks (6LoWPANs)", RFC 6568, Personal Area Networks (6LoWPANs)", RFC 6568,
DOI 10.17487/RFC6568, April 2012, DOI 10.17487/RFC6568, April 2012,
<https://www.rfc-editor.org/info/rfc6568>. <https://www.rfc-editor.org/info/rfc6568>.
[RFC6606] Kim, E., Kaspar, D., Gomez, C., and C. Bormann, "Problem
Statement and Requirements for IPv6 over Low-Power
Wireless Personal Area Network (6LoWPAN) Routing",
RFC 6606, DOI 10.17487/RFC6606, May 2012,
<https://www.rfc-editor.org/info/rfc6606>.
[RFC6620] Nordmark, E., Bagnulo, M., and E. Levy-Abegnoli, "FCFS
SAVI: First-Come, First-Served Source Address Validation
Improvement for Locally Assigned IPv6 Addresses",
RFC 6620, DOI 10.17487/RFC6620, May 2012,
<https://www.rfc-editor.org/info/rfc6620>.
[RFC6775] Shelby, Z., Ed., Chakrabarti, S., Nordmark, E., and C. [RFC6775] Shelby, Z., Ed., Chakrabarti, S., Nordmark, E., and C.
Bormann, "Neighbor Discovery Optimization for IPv6 over Bormann, "Neighbor Discovery Optimization for IPv6 over
Low-Power Wireless Personal Area Networks (6LoWPANs)", Low-Power Wireless Personal Area Networks (6LoWPANs)",
RFC 6775, DOI 10.17487/RFC6775, November 2012, RFC 6775, DOI 10.17487/RFC6775, November 2012,
<https://www.rfc-editor.org/info/rfc6775>. <https://www.rfc-editor.org/info/rfc6775>.
[RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for [RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for
Constrained-Node Networks", RFC 7228, Constrained-Node Networks", RFC 7228,
DOI 10.17487/RFC7228, May 2014, DOI 10.17487/RFC7228, May 2014,
<https://www.rfc-editor.org/info/rfc7228>. <https://www.rfc-editor.org/info/rfc7228>.
skipping to change at page 21, line 42 skipping to change at page 24, line 47
Network (6LoWPAN) ESC Dispatch Code Points and Network (6LoWPAN) ESC Dispatch Code Points and
Guidelines", RFC 8066, DOI 10.17487/RFC8066, February Guidelines", RFC 8066, DOI 10.17487/RFC8066, February
2017, <https://www.rfc-editor.org/info/rfc8066>. 2017, <https://www.rfc-editor.org/info/rfc8066>.
[RFC8105] Mariager, P., Petersen, J., Ed., Shelby, Z., Van de Logt, [RFC8105] Mariager, P., Petersen, J., Ed., Shelby, Z., Van de Logt,
M., and D. Barthel, "Transmission of IPv6 Packets over M., and D. Barthel, "Transmission of IPv6 Packets over
Digital Enhanced Cordless Telecommunications (DECT) Ultra Digital Enhanced Cordless Telecommunications (DECT) Ultra
Low Energy (ULE)", RFC 8105, DOI 10.17487/RFC8105, May Low Energy (ULE)", RFC 8105, DOI 10.17487/RFC8105, May
2017, <https://www.rfc-editor.org/info/rfc8105>. 2017, <https://www.rfc-editor.org/info/rfc8105>.
[RFC8138] Thubert, P., Ed., Bormann, C., Toutain, L., and R. Cragie,
"IPv6 over Low-Power Wireless Personal Area Network
(6LoWPAN) Routing Header", RFC 8138, DOI 10.17487/RFC8138,
April 2017, <https://www.rfc-editor.org/info/rfc8138>.
[RFC8163] Lynn, K., Ed., Martocci, J., Neilson, C., and S. [RFC8163] Lynn, K., Ed., Martocci, J., Neilson, C., and S.
Donaldson, "Transmission of IPv6 over Master-Slave/Token- Donaldson, "Transmission of IPv6 over Master-Slave/Token-
Passing (MS/TP) Networks", RFC 8163, DOI 10.17487/RFC8163, Passing (MS/TP) Networks", RFC 8163, DOI 10.17487/RFC8163,
May 2017, <https://www.rfc-editor.org/info/rfc8163>. May 2017, <https://www.rfc-editor.org/info/rfc8163>.
[RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(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>.
[RFC8352] Gomez, C., Kovatsch, M., Tian, H., and Z. Cao, Ed., [RFC8352] Gomez, C., Kovatsch, M., Tian, H., and Z. Cao, Ed.,
"Energy-Efficient Features of Internet of Things "Energy-Efficient Features of Internet of Things
Protocols", RFC 8352, DOI 10.17487/RFC8352, April 2018, Protocols", RFC 8352, DOI 10.17487/RFC8352, April 2018,
<https://www.rfc-editor.org/info/rfc8352>. <https://www.rfc-editor.org/info/rfc8352>.
[RFC8376] Farrell, S., Ed., "Low-Power Wide Area Network (LPWAN)
Overview", RFC 8376, DOI 10.17487/RFC8376, May 2018,
<https://www.rfc-editor.org/info/rfc8376>.
[RFC8505] Thubert, P., Ed., Nordmark, E., Chakrabarti, S., and C. [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>.
[RFC8928] Thubert, P., Ed., Sarikaya, B., Sethi, M., and R. Struik,
"Address-Protected Neighbor Discovery for Low-Power and
Lossy Networks", RFC 8928, DOI 10.17487/RFC8928, November
2020, <https://www.rfc-editor.org/info/rfc8928>.
[RFC8929] Thubert, P., Ed., Perkins, C., and E. Levy-Abegnoli, "IPv6
Backbone Router", RFC 8929, DOI 10.17487/RFC8929, November
2020, <https://www.rfc-editor.org/info/rfc8929>.
[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 2003,
<https://global.ihs.com/ <https://global.ihs.com/
doc_detail.cfm?item_s_key=00032964>. doc_detail.cfm?item_s_key=00032964>.
Appendix A. Design Space Dimensions for 6lo Deployment Appendix A. Design Space Dimensions for 6lo Deployment
The [RFC6568] lists the dimensions used to describe the design space The [RFC6568] lists the dimensions used to describe the design space
skipping to change at page 23, line 48 skipping to change at page 27, line 23
o Power use strategy: to enable certain use cases, there may be o Power use strategy: to enable certain use cases, there may be
requirements on the class of energy availability and the strategy requirements on the class of energy availability and the strategy
followed for using power for communication [RFC7228]. Each link followed for using power for communication [RFC7228]. Each link
layer technology defines a particular power use strategy which may layer technology defines a particular power use strategy which may
be tuned [RFC8352]. Readers are expected to be familiar with be tuned [RFC8352]. Readers are expected to be familiar with
[RFC7228] terminology. [RFC7228] terminology.
o Update firmware requirements: Most 6lo use cases will need a o Update firmware requirements: Most 6lo use cases will need a
mechanism for updating firmware. In these cases support for over mechanism for updating firmware. In these cases support for over
the air updates are required, probably in a broadcast mode when the air updates are required, probably in a broadcast mode when
bandwith is low and the number of identical devices is high. bandwidth is low and the number of identical devices is high.
o Wired vs. Wireless: Plenty of 6lo link layer technologies are o Wired vs. Wireless: Plenty of 6lo link layer technologies are
wireless, except MS/TP and PLC. The selection of wired or wireless, except MS/TP and PLC. The selection of wired or
wireless link layer technology is mainly dependent on the wireless link layer technology is mainly dependent on the
requirement of 6lo use cases and the characteristics of wired/ requirement of 6lo use cases and the characteristics of wired/
wireless technologies. For example, some 6lo use cases may wireless technologies. For example, some 6lo use cases may
require easy and quick deployment, whereas others may need a require easy and quick deployment, whereas others may need a
continuous source of power. continuous source of power.
Authors' Addresses Authors' Addresses
Yong-Geun Hong Yong-Geun Hong
ETRI Daejeon
218 Gajeongno, Yuseong
Daejeon 34129
Korea Korea
Phone: +82 42 860 6557 Email: yonggeun.hong@gmail.com
Email: yghong@etri.re.kr
Carles Gomez Carles Gomez
Universitat Politecnica de Catalunya/Fundacio i2cat Universitat Politecnica de Catalunya/Fundacio i2cat
C/Esteve Terradas, 7 C/Esteve Terradas, 7
Castelldefels 08860 Castelldefels 08860
Spain Spain
Email: carlesgo@entel.upc.edu Email: carlesgo@entel.upc.edu
Younghwan Choi Younghwan Choi
ETRI ETRI
218 Gajeongno, Yuseong 218 Gajeongno, Yuseong
Daejeon 34129 Daejeon 34129
Korea 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
Huaiyin Institute of Technology Huaiyin Institute of Technology
No.89 North Beijing Road, Qinghe District No.89 North Beijing Road, Qinghe District
Huaian 223001 Huaian 223001
P.R. China P.R. China
Email: sangi_bahrian@yahoo.com Email: sangi_bahrian@yahoo.com
Take Aanstoot
Modio AB
S:t Larsgatan 15, 582 24
Linkoping
Sweden
Email: take@modio.se
Samita Chakrabarti Samita Chakrabarti
San Jose, CA San Jose, CA
USA USA
Email: samitac.ietf@gmail.com Email: samitac.ietf@gmail.com
 End of changes. 101 change blocks. 
372 lines changed or deleted 531 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/