rfc9453.original.xml   rfc9453.xml 
<?xml version='1.0' encoding='utf-8'?> <?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE rfc [ <!DOCTYPE rfc [
<!ENTITY nbsp "&#160;"> <!ENTITY nbsp "&#160;">
<!ENTITY zwsp "&#8203;"> <!ENTITY zwsp "&#8203;">
<!ENTITY nbhy "&#8209;"> <!ENTITY nbhy "&#8209;">
<!ENTITY wj "&#8288;"> <!ENTITY wj "&#8288;">
]> ]>
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" category="info" docName="draft-i
etf-6lo-use-cases-16" ipr="trust200902" obsoletes="" updates="" submissionType="
IETF" xml:lang="en" tocInclude="true" tocDepth="4" symRefs="true" sortRefs="true
" version="3">
<!-- xml2rfc v2v3 conversion 3.15.1 -->
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<!-- used by XSLT processors -->
<!-- For a complete list and description of processing instructions (PIs),
please see http://xml.resource.org/authoring/README.html. -->
<!-- Below are generally applicable Processing Instructions (PIs) that most I-
Ds might want to use.
(Here they are set differently than their defaults in xml2rfc v1.32) -->
<!-- give errors regarding ID-nits and DTD validation -->
<!-- control the table of contents (ToC) -->
<!-- generate a ToC -->
<!-- the number of levels of subsections in ToC. default: 3 -->
<!-- control references -->
<!-- use symbolic references tags, i.e, [RFC2119] instead of [1] -->
<!-- sort the reference entries alphabetically -->
<!-- control vertical white space
(using these PIs as follows is recommended by the RFC Editor) -->
<!-- do not start each main section on a new page -->
<!-- keep one blank line between list items -->
<!-- end of list of popular I-D processing instructions -->
<!-- ***** FRONT MATTER ***** --> <rfc xmlns:xi="http://www.w3.org/2001/XInclude" submissionType="IETF" category="
<front> info" consensus="true" docName="draft-ietf-6lo-use-cases-16" number="9453" ipr="
<!-- The abbreviated title is used in the page header - it is only necessary trust200902" obsoletes="" updates="" xml:lang="en" tocInclude="true" tocDepth="4
if the " symRefs="true" sortRefs="true" version="3">
full title is longer than 39 characters -->
<title abbrev="6lo Applicability &amp; Use cases">IPv6 over Constrained Node <front>
Networks (6lo) Applicability &amp; Use cases</title> <title abbrev="6lo Applicability and Use Cases">Applicability and Use Cases
<seriesInfo name="Internet-Draft" value="draft-ietf-6lo-use-cases-16"/> for IPv6 over Networks of Resource-constrained Nodes (6lo)</title>
<!-- add 'role="editor"' below for the editors if appropriate --> <seriesInfo name="RFC" value="9453"/>
<!-- Another author who claims to be an editor -->
<author fullname="Yong-Geun Hong" initials="Y-G" surname="Hong"> <author fullname="Yong-Geun Hong" initials="Y-G" surname="Hong">
<organization>Daejeon University</organization> <organization>Daejeon University</organization>
<address> <address>
<postal> <postal>
<street>62 Daehak-ro, Dong-gu</street> <street>62 Daehak-ro, Dong-gu</street>
<street/>
<city>Daejeon</city> <city>Daejeon</city>
<region/> <region/>
<code>34520</code> <code>34520</code>
<country>South Korea</country> <country>South Korea</country>
</postal> </postal>
<phone>+82 42 280 4841</phone> <phone>+82 42 280 4841</phone>
<email>yonggeun.hong@gmail.com</email> <email>yonggeun.hong@gmail.com</email>
<!-- uri and facsimile elements may also be added -->
</address> </address>
</author> </author>
<author initials="C.G." surname="Gomez" fullname="Carles Gomez"> <author initials="C." surname="Gomez" fullname="Carles Gomez">
<organization abbrev="UPC">Universitat Politecnica de Catalunya/Fundacio i <organization abbrev="UPC">Universitat Politecnica de Catalunya</organizat
2cat</organization> ion>
<address> <address>
<postal> <postal>
<street>C/Esteve Terradas, 7</street> <street>C/Esteve Terradas, 7</street>
<code>08860</code> <code>08860</code>
<city>Castelldefels</city> <city>Castelldefels</city>
<country>Spain</country> <country>Spain</country>
</postal> </postal>
<email>carles.gomez@upc.edu</email> <email>carles.gomez@upc.edu</email>
</address> </address>
</author> </author>
<author fullname="Younghwan Choi" initials="Y-H" surname="Choi"> <author fullname="Younghwan Choi" initials="Y-H" surname="Choi">
<organization abbrev="ETRI">ETRI</organization> <organization abbrev="ETRI">ETRI</organization>
<address> <address>
<postal> <postal>
<street>218 Gajeongno, Yuseong</street> <street>218 Gajeongno, Yuseong</street>
<street/>
<city>Daejeon</city> <city>Daejeon</city>
<region/> <region/>
<code>34129</code> <code>34129</code>
<country>South Korea</country> <country>South Korea</country>
</postal> </postal>
<phone>+82 42 860 1429</phone> <phone>+82 42 860 1429</phone>
<email>yhc@etri.re.kr</email> <email>yhc@etri.re.kr</email>
</address> </address>
</author> </author>
<author fullname="Abdur Rashid Sangi" initials="AR." surname="Sangi"> <author fullname="Abdur Rashid Sangi" initials="A." surname="Sangi">
<organization>Wenzhou-Kean University</organization> <organization>Wenzhou-Kean University</organization>
<address> <address>
<postal> <postal>
<street>88 Daxue Road, Ouhai, Wenzhou</street> <street>88 Daxue Road, Ouhai, Wenzhou</street>
<city>Zhejiang</city> <city>Zhejiang</city>
<region/> <region/>
<code>325060</code> <code>325060</code>
<country>P.R. China</country> <country>China</country>
</postal> </postal>
<phone/> <phone/>
<email>sangi_bahrian@yahoo.com</email> <email>sangi_bahrian@yahoo.com</email>
</address> </address>
</author> </author>
<author fullname="Samita Chakrabarti" initials="S." surname="Chakrabarti"> <author fullname="Samita Chakrabarti" initials="S." surname="Chakrabarti">
<organization/> <organization>Verizon</organization>
<address> <address>
<postal> <postal>
<street/> <street/>
<city>San Jose, CA</city> <city>Bedminster</city>
<region/> <region>NJ</region>
<code/> <code/>
<country>USA</country> <country>United States of America</country>
</postal> </postal>
<phone/> <phone/>
<email>samitac.ietf@gmail.com</email> <email>samita.chakrabarti@verizon.com </email>
</address> </address>
</author> </author>
<date day="5" month="April" year="2023"/>
<!-- If the month and year are both specified and are the current ones, xml2
rfc will fill
in the current day for you. If only the current year is specified, xml2rfc
will fill
in the current day and month for you. If the year is not the current one
, it is
necessary to specify at least a month (xml2rfc assumes day="1" if not sp
ecified for the
purpose of calculating the expiry date). With drafts it is normally suf
ficient to
specify just the year. -->
<!-- Meta-data Declarations --> <date month="September" year="2023"/>
<area>Internet</area>
<workgroup>6Lo Working Group</workgroup>
<!-- WG name at the upperleft corner of the doc,
IETF is fine for individual submissions.
If this element is not present, the default is "Network Working Group",
which is used by the RFC Editor as a nod to the history of the IETF. -->
<keyword>Internet Draft</keyword> <area>int</area>
<!-- Keywords will be incorporated into HTML output <workgroup>6lo</workgroup>
files in a meta tag but they have no effect on text or nroff
output. If you submit your draft to the RFC Editor, the
keywords will be used for the search engine. -->
<!-- Abstract section -->
<abstract> <abstract>
<t>This document describes the applicability of IPv6 over constrained node <t>This document describes the applicability of IPv6 over
networks (6lo) and provides practical deployment examples. In addition to IEEE constrained-node networks (6lo) and provides practical deployment
Std 802.15.4, various link layer technologies such as ITU-T G.9959 (Z-Wave), Blu examples. In addition to IEEE Std 802.15.4, various link-layer
etooth Low Energy (Bluetooth LE), Digital Enhanced Cordless Telecommunications-U technologies are used as examples, such as ITU-T G.9959 (Z-Wave),
ltra Low Energy (DECT-ULE), Master-Slave/Token Passing (MS/TP), Near Field Commu Bluetooth Low Energy (Bluetooth LE), Digital Enhanced Cordless Telecommuni
nication (NFC), and Power Line Communication (PLC) are used as examples. The doc cations
ument targets an audience who would like to understand and evaluate running end- - Ultra Low Energy (DECT-ULE), Master-Slave/Token Passing (MS/TP), Near
to-end IPv6 over the constrained node networks for local or Internet connectivit Field Communication (NFC), and Power Line Communication (PLC). This
y.</t> document targets an audience who would like to understand and evaluate
running end-to-end IPv6 over the constrained-node networks for local or
Internet connectivity.</t>
</abstract> </abstract>
</front> </front>
<middle> <middle>
<!-- Section 1 - Introductiontion -->
<section numbered="true" toc="default"> <section numbered="true" toc="default">
<name>Introduction</name> <name>Introduction</name>
<t>Running IPv6 on constrained node networks presents challenges, due to t <t>Running IPv6 on constrained-node networks presents challenges due to
he characteristics of these networks such as small packet size, low power, low b the characteristics of these networks, such as small packet size, low
andwidth, and large number of devices, among others <xref target="RFC4919" forma power, low bandwidth, and large number of devices, among others <xref
t="default"/><xref target="RFC7228" format="default"/>. For example, many IEEE S target="RFC4919" format="default"/> <xref target="RFC7228"
td 802.15.4 variants <xref target="IEEE802154" format="default"/> exhibit a fram format="default"/>. For example, many IEEE Std 802.15.4 variants <xref
e size of 127 octets, whereas IPv6 requires its underlying layer to support an M target="IEEE-802.15.4" format="default"/> exhibit a frame size of 127
TU of 1280 bytes. Furthermore, those IEEE Std 802.15.4 variants do not offer fra octets, whereas IPv6 requires its underlying layer to support an MTU of
gmentation and reassembly functionality. (It is noted that IEEE Std 802.15.9-202 1280 bytes. Furthermore, those IEEE Std 802.15.4 variants do not offer
1 provides a multiplexing and fragmentation layer for the IEEE Std 802.15.4 <xre fragmentation and reassembly functionality. (It is noted that IEEE Std
f target="IEEE802159" format="default"/>.) Therefore, an appropriate adaptation 802.15.9-2021 provides a multiplexing and fragmentation layer for the
layer supporting fragmentation and reassembly must be provided below IPv6. Also, IEEE Std 802.15.4 <xref target="IEEE-802.15.9" format="default"/>.)
the limited IEEE Std 802.15.4 frame size and low energy consumption requirement Therefore, an appropriate adaptation layer supporting fragmentation and
s motivate the need for packet header compression. The IETF IPv6 over Low-Power reassembly must be provided below IPv6. Also, the limited IEEE Std
WPAN (6LoWPAN) working group published a suite of specifications that provide an 802.15.4 frame size and low energy consumption requirements motivate the
adaptation layer to support IPv6 over IEEE Std 802.15.4 comprising the followin need for packet header compression. The IETF IPv6 over Low-Power
g functionality: </t> Wireless Personal Area Network (6LoWPAN) Working Group published a suite
of specifications that provides an adaptation layer to support IPv6 over
IEEE Std 802.15.4 comprising the following functionalities: </t>
<ul spacing="normal"> <ul spacing="normal">
<li> Fragmentation and reassembly, address autoconfiguration, and a fram <li>fragmentation and reassembly, address autoconfiguration, and a
e format <xref target="RFC4944" format="default"/>,</li> frame format <xref target="RFC4944" format="default"/></li>
<li> IPv6 (and UDP) header compression <xref target="RFC6282" format="de <li>IPv6 (and UDP) header compression <xref target="RFC6282"
fault"/>,</li> format="default"/></li>
<li> Neighbor Discovery Optimization for 6LoWPAN <xref target="RFC6775" <li>Neighbor Discovery Optimization for 6LoWPAN <xref target="RFC6775"
format="default"/><xref target="RFC8505" format="default"/>.</li> format="default"/> <xref target="RFC8505" format="default"/></li>
</ul> </ul>
<t>As Internet of Things (IoT) services become more popular, the IETF has <t>As Internet of Things (IoT) services become more popular, the IETF has
defined adaptation layer functionality to support IPv6 over various link layer t defined adaptation layer functionality to support IPv6 over various link-layer t
echnologies other than IEEE Std 802.15.4, such as Bluetooth Low Energy (Bluetoot echnologies other than IEEE Std 802.15.4, such as Bluetooth Low Energy (Bluetoot
h LE), ITU-T G.9959 (Z-Wave), Digital Enhanced Cordless Telecommunications - Ult h LE), ITU-T G.9959 (Z-Wave), Digital Enhanced Cordless Telecommunications - Ult
ra Low Energy (DECT-ULE), Master-Slave/Token Passing (MS/TP), Near Field Communi ra Low Energy (DECT-ULE), Master-Slave/Token Passing (MS/TP), Near Field Communi
cation (NFC), and Power Line Communication (PLC). The 6lo adaptation layers use cation (NFC), and Power Line Communication (PLC). The 6lo adaptation layers use
a variation of the 6LoWPAN stack applied to each particular link layer technolog a variation of the 6LoWPAN stack applied to each particular link-layer technolog
y.</t> y.</t>
<t>The 6LoWPAN working group produced the document entitled "Design and Ap <t>The 6LoWPAN Working Group produced the document entitled "<xref
plication Spaces for 6LoWPANs" <xref target="RFC6568" format="default"/>, which target="RFC6568" format="title"/>" <xref target="RFC6568"
describes potential application scenarios and use cases for low-power wireless p format="default"/>, which describes potential application scenarios and
ersonal area networks. The present document aims to provide guidance to an audie use cases for LoWPANs. The present document aims to provide guidance to
nce who are new to the IPv6 over constrained node networks (6lo) concept and wan an audience that is new to the IPv6 over constrained-node networks (6lo)
t to assess its application to the constrained node network of their interest. T concept and want to assess its application to the constrained-node
his 6lo applicability document describes a few sets of practical 6lo deployment network of their interest. This 6lo applicability document describes a
scenarios and use cases examples. In addition, it considers various network desi few sets of practical 6lo deployment scenarios and use-case
gn space dimensions such as deployment, network size, power source, connectivity examples. In addition, it considers various network design space
, multi-hop communication, traffic pattern, security level, mobility, and QoS re dimensions, such as Deployment, Network Size, Power Source,
quirements (see Appendix A). Connectivity, Multi-Hop Communication, Traffic pattern,
Mobility, and QoS requirements (see <xref target="appendix-a"/>).
</t> </t>
<t>This document provides the applicability and use cases of 6lo, consider <t>This document provides the applicability and use cases of 6lo,
ing the following aspects:</t> considering the following aspects:</t>
<ul spacing="normal"> <ul spacing="normal">
<li> It covers various IoT-related wired/wireless link layer technologie <li>Various IoT-related wired or wireless link-layer technologies
s providing practical information about such technologies.</li> providing practical information about such technologies.</li>
<li> It provides a general guideline on how the 6LoWPAN stack can be mod <li>General guidelines on how the 6LoWPAN stack can be modified for a
ified for a given L2 technology.</li> given L2 technology.</li>
<li> Various 6lo use cases and practical deployment examples are describ <li>Various 6lo use cases and practical deployment examples.</li>
ed.</li>
</ul> </ul>
<t>Note that the use of "master" and "slave" have been retained in this document
to align with use within the industry (e.g., <xref target="TIA-485-A" format="d
efault"/> and <xref target="BACnet" format="default"/>).</t>
</section> </section>
<!-- Section 2 - 6lo Link layer technologies -->
<section numbered="true" toc="default"> <section anchor="sec2" numbered="true" toc="default">
<name>6lo Link layer technologies</name> <name>6lo Link-Layer Technologies</name>
<!-- Section 2.1 -->
<section numbered="true" toc="default"> <section numbered="true" toc="default">
<name>ITU-T G.9959</name> <name>ITU-T G.9959</name>
<t>The ITU-T G.9959 Recommendation <xref target="G.9959" format="default <t>The ITU-T G.9959 Recommendation <xref target="G.9959"
"/> targets low-power Wireless Personal Area Networks (WPANs), and defines physi format="default"/> targets LoWPANs and defines physical-layer and link-l
cal layer and link layer functionality. Physical layers of 9.6 kbit/s, 40 kbit/s ayer functionality. Physical layers of 9.6 kbit/s, 40 kbit/s, and 100
and 100 kbit/s are supported. G.9959 defines how a unique 32-bit HomeID network kbit/s are supported. <xref target="G.9959" format="default"/> defines
identifier is assigned by a network controller and how an 8-bit NodeID host ide how a unique 32-bit HomeID network identifier is assigned by a network
ntifier is allocated to each node. NodeIDs are unique within the network identif controller and how an 8-bit NodeID host identifier is allocated to
ied by the HomeID. The G.9959 HomeID represents an IPv6 subnet that is identifi each node. NodeIDs are unique within the network identified by the
ed by one or more IPv6 prefixes <xref target="RFC7428" format="default"/>. ITU-T HomeID. The G.9959 HomeID represents an IPv6 subnet that is
G.9959 can be used for smart home applications and the transmisstion rage is 10 identified by one or more IPv6 prefixes <xref target="RFC7428"
0 meters per hop.</t> format="default"/>. ITU-T G.9959 can be used for smart home
applications, and the transmission range is 100 meters per hop.</t>
</section> </section>
<!-- Section 2.2 -->
<section numbered="true" toc="default"> <section numbered="true" toc="default">
<name>Bluetooth LE</name> <name>Bluetooth LE</name>
<t>Bluetooth LE was introduced in Bluetooth 4.0, enhanced in Bluetooth 4 <t>Bluetooth LE was introduced in Bluetooth 4.0, enhanced in Bluetooth 4
.1, and developed further in successive versions. The data rate of Bluetooth LE .1, and developed further in successive versions. The data rate of Bluetooth LE
is 125 kb/s, 500 kb/s, 1 Mb/s, 2 Mb/s and max transmission range is around 100 m is 125 kb/s, 500 kb/s, 1 Mb/s, 2 Mb/s; and max transmission range is around 100
eters (outdoors). The Bluetooth SIG has also published the Internet Protocol Sup meters (outdoors). The Bluetooth Special Interest Group (Bluetooth SIG) has also
port Profile (IPSP). The IPSP enables discovery of IP-enabled devices and establ published the Internet Protocol Support Profile (IPSP). The IPSP enables discov
ishment of link-layer connections for transporting IPv6 packets. IPv6 over Bluet ery of IP-enabled devices and establishment of link-layer connections for transp
ooth LE is dependent on both Bluetooth 4.1 and IPSP 1.0 or newer <xref target="B orting IPv6 packets. IPv6 over Bluetooth LE is dependent on both Bluetooth 4.1 <
TCorev4.1" format="default"/><xref target="IPSP" format="default"/>.</t> xref target="BTCorev5.4" format="default"/> and IPSP 1.0 <xref target="IPSP" for
<t>Many devices such as mobile phones, notebooks, tablets and other hand mat="default"/> or newer.</t>
held computing devices which support Bluetooth 4.0 or subsequent versions also s <t>Many devices such as mobile phones, notebooks, tablets, and other han
upport the low-energy variant of Bluetooth. Bluetooth LE is also being included dheld computing devices that support Bluetooth 4.0 or subsequent versions also s
in many different types of accessories that collaborate with mobile devices. An upport the low-energy variant of Bluetooth. Bluetooth LE is also being included
example of a use case for a Bluetooth LE accessory is a heart rate monitor that in many different types of accessories that collaborate with mobile devices. An
sends data via the mobile phone to a server on the Internet <xref target="RFC766 example of a use case for a Bluetooth LE accessory is a heart rate monitor that
8" format="default"/>. A typical usage of Bluetooth LE is smartphone-based inter sends data via the mobile phone to a server on the Internet <xref target="RFC766
action with constrained devices. Bluetooth LE was originally designed to enable 8" format="default"/>. A typical usage of Bluetooth LE is smartphone-based inter
star topology networks. However, recent Bluetooth versions support the formatio action with constrained devices. Bluetooth LE was originally designed to enable
n of extended topologies, and IPv6 support for mesh networks of Bluetooth LE d star topology networks. However, recent Bluetooth versions support the formatio
evices has been developed <xref target="RFC9159" format="default"/>.</t> n of extended topologies, and IPv6 support for mesh networks of Bluetooth LE dev
ices has been developed <xref target="RFC9159" format="default"/>.</t>
</section> </section>
<!-- Section 2.3 -->
<section numbered="true" toc="default"> <section numbered="true" toc="default">
<name>DECT-ULE</name> <name>DECT-ULE</name>
<t>DECT-ULE is a low-power air interface technology that is designed to <t>DECT-ULE is a low-power air interface technology that is designed to
support both circuit-switched services, such as voice communication, and packet- support both circuit-switched services, such as voice communication, and packet-
mode data services at modest data rate <xref target="TS102.939-1" format="defaul mode data services at modest data rate <xref target="TS102.939-1" format="defaul
t"/><xref target="TS102.939-2" format="default"/>.</t> t"/> <xref target="TS102.939-2" format="default"/>.</t>
<t>The DECT-ULE protocol stack consists of the physical layer operating <t>The DECT-ULE protocol stack consists of the physical layer operating
at frequencies in the dedicated 1880 - 1920 MHz frequency band depending on the at frequencies in the dedicated 1880 - 1920 MHz frequency band depending on the
region and uses a symbol rate of 1.152 Mbps. Radio bearers are allocated by use region and uses a symbol rate of 1.152 Mbps. Radio bearers are allocated by use
of FDMA/TDMA/TDD techniques. The coverage distance is from 70 meters (indoors) t of Frequency-Division Multiplex (FDMA), Time-Division Multiple Access (TDMA), an
o 600 meters (outdoors).</t> d Time-Division Duplex (TDD) techniques. The coverage distance is from 70 meters
<t>In its generic network topology, DECT is defined as a cellular networ (indoors) to 600 meters (outdoors).</t>
k technology. However, the most common configuration is a star network with a si <t>In its generic network topology, DECT is defined as a cellular networ
ngle Fixed Part (FP) defining the network with a number of Portable Parts (PP) a k technology. However, the most common configuration is a star network with a si
ttached. The Medium Access Control (MAC) layer supports classical DECT as this i ngle Fixed Part (FP) defining the network with a number of Portable Parts (PPs)
s used for services like discovery, pairing, and security features. All these fe attached. The Medium Access Control (MAC) layer supports classical DECT as this
atures have been reused from DECT.</t> is used for services like discovery, pairing, and security features. All these f
<t>The DECT-ULE device can switch to the ULE mode of operation, utilizin eatures have been reused from DECT.</t>
g the new ULE MAC layer features. The DECT-ULE Data Link Control (DLC) provides <t>The DECT-ULE device can switch to the ULE mode of operation, utilizin
multiplexing as well as segmentation and re-assembly for larger packets from lay g the new Ultra Low Energy (ULE) MAC layer features. The DECT-ULE Data Link Cont
ers above. The DECT-ULE layer also implements per-message authentication and en rol (DLC) provides multiplexing as well as segmentation and re-assembly for larg
cryption. The DLC layer ensures packet integrity and preserves packet order, but er packets from layers above. The DECT-ULE layer also implements per-message au
delivery is based on best effort.</t> thentication and encryption. The DLC layer ensures packet integrity and preserve
s packet order, but delivery is based on best effort.</t>
<t>The current DECT-ULE MAC layer standard supports low bandwidth data b roadcast. However, the usage of this broadcast service has not yet been standard ized for higher layers <xref target="RFC8105" format="default"/>. DECT-ULE can b e used for smart metering in a home.</t> <t>The current DECT-ULE MAC layer standard supports low bandwidth data b roadcast. However, the usage of this broadcast service has not yet been standard ized for higher layers <xref target="RFC8105" format="default"/>. DECT-ULE can b e used for smart metering in a home.</t>
</section> </section>
<!-- Section 2.4 -->
<section numbered="true" toc="default"> <section numbered="true" toc="default">
<name>MS/TP</name> <name>MS/TP</name>
<t>MS/TP is a MAC protocol for the RS-485 <xref target="TIA-485-A" forma t="default"/> physical layer and is used primarily in building automation networ ks.</t> <t>MS/TP is a MAC protocol for the RS-485 <xref target="TIA-485-A" forma t="default"/> physical layer and is used primarily in building automation networ ks.</t>
<t>An MS/TP device is typically based on a low-cost microcontroller with <t>An MS/TP device is typically based on a low-cost microcontroller with
limited processing power and memory. These constraints, together with low da limited processing power and memory. These constraints, together with low da
ta rates and a small MAC address space, are similar to those faced in 6LoWPAN ne ta rates and a small MAC address space, are similar to those faced in 6LoWPAN ne
tworks. MS/TP differs significantly from 6LoWPAN in at least three respects: a) tworks. MS/TP differs significantly from 6LoWPAN in at least three respects:</t
MS/TP devices are typically mains powered, b) all MS/TP devices on a segment ca >
n communicate directly so there are no hidden node or mesh routing issues, and c <ol spacing="normal" type="a">
) the latest MS/TP specification provides support for large payloads, eliminatin <li>MS/TP devices are typically mains powered.</li>
g the need for fragmentation and reassembly below IPv6.</t> <li>All MS/TP devices on a segment can communicate directly, so there are
<t>MS/TP is designed to enable multidrop networks over shielded twisted no hidden node issues or mesh routing issues.</li>
pair wiring. It can support network segments up to 1000 meters in length at a da <li>The latest MS/TP specification provides support for large payloads,
ta rate of 115.2 kbit/s or segments up to 1200 meters in length at lower bit rat eliminating the need for fragmentation and reassembly below
es. An MS/TP interface requires only a Universal Asynchronous Receiver-Transmitt IPv6.</li></ol>
er (UART), an RS-485 <xref target="TIA-485-A" format="default"/> transceiver wit <t>MS/TP is designed to enable multidrop networks over shielded twisted
h a driver that can be disabled, and a 5 ms resolution timer. The MS/TP MAC is pair wiring. It can support network segments up to 1000 meters in length at a da
typically implemented in software.</t> ta rate of 115.2 kbit/s or segments up to 1200 meters in length at lower bit rat
<t>Because of its long-range (~1 km), MS/TP can be used to connect remot es. An MS/TP interface requires only a Universal Asynchronous Receiver Transmitt
e devices (such as district heating controllers) to the nearest building control er (UART), an RS-485 <xref target="TIA-485-A" format="default"/> transceiver wit
infrastructure over a single link <xref target="RFC8163" format="default"/>. </ h a driver that can be disabled, and a 5 ms resolution timer. The MS/TP MAC is
t> typically implemented in software.</t>
<t>Because of its long range (~1 km), MS/TP can be used to connect remot
e devices (such as district heating controllers) to the nearest building control
infrastructure over a single link <xref target="RFC8163" format="default"/>. </
t>
</section> </section>
<!-- Section 2.5 -->
<section numbered="true" toc="default"> <section numbered="true" toc="default">
<name>NFC</name> <name>NFC</name>
<t>NFC technology enables secure interactions between electronic devices
, allowing consumers to perform contactless transactions, access digital content <t>NFC technology enables secure interactions between electronic devices
, and connect electronic devices with a single touch <xref target="LLCP-1.4" for , allowing consumers to perform contactless transactions, access digital content
mat="default"/>. The distance between sender and receiver is 10 cm or less. NFC , and connect electronic devices with a single touch <xref target="LLCP-1.4" for
complements many popular consumer-level wireless technologies, by utilizing the mat="default"/>. The distance between sender and receiver is 10 cm or less. NFC
key elements in existing standards for contactless card technology (ISO/IEC 1444 complements many popular consumer-level wireless technologies by utilizing the k
3 A&amp;B and JIS-X 6319-4).</t> ey elements in existing standards for contactless card technology.</t>
<t>Extending the capability of contactless card technology, NFC also ena <t>Extending the capability of contactless card technology, NFC also
bles devices to share information at a distance that is less than 10 cm with a m enables devices to share information at a distance that is less than
aximum communication speed of 424 kbps. Users can share business cards, make tra 10 cm with a maximum communication speed of 424 kbps. Users can share
nsactions, access information from a smart poster or provide credentials for acc business cards, make transactions, access information from a smart
ess control systems with a simple touch.</t> poster, or provide credentials for access control systems with a
<t>NFC's bidirectional communication ability is suitable for establishin simple touch.</t>
g connections with other technologies by the simplicity of touch. In addition to <t>NFC's bidirectional communication ability is suitable for establishin
the easy connection and quick transactions, simple data sharing is available <x g connections with other technologies by the simplicity of touch. In addition to
ref target="I-D.ietf-6lo-nfc" format="default"/>. NFC can be used for secure tra the easy connection and quick transactions, simple data sharing is available <x
nsfer services where privacy is important.</t> ref target="RFC9428" format="default"/>. NFC can be used for secure transfer ser
vices where privacy is important.</t>
</section> </section>
<!-- Section 2.6 -->
<section numbered="true" toc="default"> <section numbered="true" toc="default">
<name>PLC</name> <name>PLC</name>
<t>PLC is a data transmission technique that utilizes power conductors a s medium <xref target="RFC9354" format="default"/>. Unlike other dedicated commu nication infrastructure, power conductors are widely available indoors and outdo ors. Moreover, wired technologies cause less interference to the radio medium th an wireless technologies and are more reliable than their wireless counterparts. </t> <t>PLC is a data transmission technique that utilizes power conductors a s the medium <xref target="RFC9354" format="default"/>. Unlike other dedicated c ommunication infrastructure, power conductors are widely available indoors and o utdoors. Moreover, wired technologies cause less interference to the radio mediu m than wireless technologies and are more reliable than their wireless counterpa rts.</t>
<t>The table below shows some available open standards defining PLC.</t> <t>The table below shows some available open standards defining PLC.</t>
<table anchor="table_PLC" align="center"> <table anchor="table_PLC" align="center">
<name>Some Available Open Standards in PLC</name> <name>Some Available Open Standards in PLC</name>
<thead> <thead>
<tr> <tr>
<th align="center">PLC Systems</th> <th align="center">PLC Systems</th>
<th align="center">Frequency Range</th> <th align="center">Frequency Range</th>
<th align="center">Type</th> <th align="center">Type</th>
<th align="center">Data Rate</th> <th align="center">Data Rate</th>
<th align="center">Distance</th> <th align="center">Distance</th>
</tr> </tr>
</thead> </thead>
<tbody> <tbody>
<tr> <tr>
<td align="center">IEEE 1901</td> <td align="center">IEEE 1901</td>
<td align="center">&lt;100MHz</td> <td align="center">&lt; 100 MHz</td>
<td align="center">Broadband</td> <td align="center">Broadband</td>
<td align="center">200Mbps</td> <td align="center">200 Mbps</td>
<td align="center">1000m</td> <td align="center">1000 m</td>
</tr> </tr>
<tr> <tr>
<td align="center">IEEE 1901.1</td> <td align="center">IEEE 1901.1</td>
<td align="center">&lt;12MHz</td> <td align="center">&lt; 12 MHz</td>
<td align="center">PLC-IoT</td> <td align="center">PLC-IoT</td>
<td align="center">10Mbps</td> <td align="center">10 Mbps</td>
<td align="center">2000m</td> <td align="center">2000 m</td>
</tr> </tr>
<tr> <tr>
<td align="center">IEEE 1901.2</td> <td align="center">IEEE 1901.2</td>
<td align="center">&lt;500kHz</td> <td align="center">&lt; 500 kHz</td>
<td align="center">Narrowband</td> <td align="center">Narrowband</td>
<td align="center">200kbps</td> <td align="center">200 kbps</td>
<td align="center">3000m</td> <td align="center">3000 m</td>
</tr> </tr>
<tr> <tr>
<td align="center">G3-PLC</td> <td align="center">G3-PLC</td>
<td align="center">&lt;500kHz</td> <td align="center">&lt; 500 kHz</td>
<td align="center">Narrowband</td> <td align="center">Narrowband</td>
<td align="center">234kbps</td> <td align="center">234 kbps</td>
<td align="center">3000m</td> <td align="center">3000 m</td>
</tr> </tr>
</tbody> </tbody>
</table> </table>
<t>IEEE Std 1901 <xref target="IEEE1901" format="default"/> defines a br <t>IEEE Std 1901 <xref target="IEEE-1901" format="default"/> defines a b
oadband variant of PLC but it is only effective within short range. This standar roadband variant of PLC, but it is only effective within short range. This stand
d addresses the requirements of high data rates such as Internet, HDTV, audio, g ard addresses the requirements of high data rates such as the Internet, HDTV, au
aming.</t> dio, and gaming.</t>
<t>IEEE Std 1901.1 <xref target="IEEE1901.1" format="default"/> defines <t>IEEE Std 1901.1 <xref target="IEEE-1901.1" format="default"/> defines
a medium frequency band (less than 12 MHz) broadband PLC technology for smart gr a medium frequency band (less than 12 MHz) broadband PLC technology for smart g
id applications based on OFDM(Orthogonal Frequency Division Multiplexing). By ac rid applications based on Orthogonal Frequency Division Multiplexing (OFDM). By
hieving an extended communication range with medium speeds, this standard can be achieving an extended communication range with medium speeds, this standard can
applied both in indoor and outdoor scenarios, such as Advanced Metering Infrast be applied in both indoor and outdoor scenarios, such as Advanced Metering Infra
ructure (AMI), street lighting, electric vehicle charging, smart city.</t> structure (AMI), street lighting, electric vehicle charging, and a smart city.</
<t>IEEE Std 1901.2 <xref target="IEEE1901.2" format="default"/> defines t>
a narrowband variant of PLC with lower data rate but significantly higher transm <t>IEEE Std 1901.2 <xref target="IEEE-1901.2" format="default"/> defines
ission range that could be used in an indoor or even an outdoor environment. A t a narrowband variant of PLC with a lower data rate but a significantly higher t
ypical use case of PLC is smart grid.</t> ransmission range that could be used in an indoor or even an outdoor environment
<t>G3-PLC <xref target="G3-PLC" format="default"/> is a narrowband PLC t . A typical use case of PLC is a smart grid.</t>
echnology that is based on the ITU-T G.9903 Recommendation <xref target="G.9903" <t>G3-PLC <xref target="G3-PLC" format="default"/> is a narrowband PLC t
format="default"/>. The ITU-T G.9903 Recommendation contains the physical layer echnology that is based on the ITU-T G.9903 Recommendation <xref target="G.9903"
and data link layer specification for the G3-PLC narrowband OFDM power line com format="default"/>. The ITU-T G.9903 Recommendation contains the physical layer
munication transceivers, for communications via alternating current and direct c and data link-layer specification for the G3-PLC narrowband OFDM power line com
urrent electric power lines over frequency bands below 500 kHz.</t> munication transceivers, for communications via alternating current and direct c
urrent electric power lines over frequency bands below 500 kHz.</t>
</section> </section>
<!-- Section 2.7 -->
<section numbered="true" toc="default"> <section numbered="true" toc="default">
<name>Comparison between 6lo link layer technologies</name> <name>Comparison between 6lo Link-Layer Technologies</name>
<t>In the above subsections, various 6lo link layer technologies are des <t>In the above subsections, various 6lo link-layer technologies are des
cribed. The following table shows the dominant parameters of each use case corre cribed. The following table shows the dominant parameters of each use case corre
sponding to the 6lo link layer technology.</t> sponding to the 6lo link-layer technology.</t>
<artwork name="" type="" align="left" alt=""><![CDATA[
+--------------+---------+---------+---------+---------+---------+---------+
| | Z-Wave |Bluetooth| DECT-ULE| MS/TP | NFC | PLC |
| | | LE | | | | |
+--------------+---------+---------+---------+---------+---------+---------+
| | Home | Interact| Meter | Building| Secure | Smart |
| Usage | Auto- | w/ Smart| Reading | Auto- | Transfer| Grid |
| | mation | Phone | | mation | | |
+--------------+---------+---------+---------+---------+---------+---------+
| Topology | L2-mesh | Star | Star | MS/TP | P2P | Star |
| & | or | & | No mesh | No mesh | L2-mesh | Tree |
| Subnet | L3-mesh | Mesh | | | | Mesh |
+--------------+---------+---------+---------+---------+---------+---------+
| Mobility | | | | | | |
| Requirement | No | Yes | No | No | Yes | No |
| | | | | | | |
+--------------+---------+---------+---------+---------+---------+---------+
| Buffering | | | | | | |
| Requirement | Yes | Yes | Yes | Yes | Yes | Yes |
| | | | | | | |
+--------------+---------+---------+---------+---------+---------+---------+
| Latency, | | | | | | |
| QoS | Yes | Yes | Yes | Yes | Yes | Yes |
| Requirement | | | | | | |
+--------------+---------+---------+---------+---------+---------+---------+
| Frequent | | | | | | |
| Transmission | No | No | No | Yes | No | No |
| Requirement | | | | | | |
+--------------+---------+---------+---------+---------+---------+---------+
| RFC # | | RFC7668 | | | draft- | |
| or | RFC7428 | RFC9159 | RFC8105 | RFC8163 | ietf-6lo| RFC9354 |
| Draft | | | | | -nfc | |
+--------------+---------+---------+---------+---------+---------+---------+
Table 2: Comparison between 6lo link layer technologies <table anchor="table2" align="center">
<name>Comparison between 6lo Link-Layer Technologies</name>
<thead>
<tr>
<th></th>
<th align="center">Z-Wave</th>
<th align="center">Bluetooth LE</th>
<th align="center">DECT-ULE</th>
<th align="center">MS/TP</th>
<th align="center">NFC</th>
<th align="center">PLC</th>
</tr>
</thead>
<tbody>
<tr>
<th align="center">Usage</th>
<td align="center">Home Autom.</td>
<td align="center">Interact w/ Smart Phone</td>
<td align="center">Meter Reading</td>
<td align="center">Building Autom.</td>
<td align="center">Secure Transfer</td>
<td align="center">Smart Grid</td>
</tr>
<tr>
<th align="center">Topology<br/>&amp;<br/>Subnet</th>
<td align="center">L2-mesh<br/>or<br/>L3-mesh</td>
<td align="center">Star &amp; Mesh</td>
<td align="center">Star, No&nbsp;mesh</td>
<td align="center">MS/TP, No&nbsp;mesh</td>
<td align="center">P2P, L2&nbhy;mesh</td>
<td align="center">Star&nbsp;Tree Mesh</td>
</tr>
<tr>
<th align="center">Mobility Req.</th>
<td align="center">No</td>
<td align="center">Yes</td>
<td align="center">No</td>
<td align="center">No</td>
<td align="center">Yes</td>
<td align="center">No</td>
</tr>
<tr>
<th align="center">Buffering Req.</th>
<td align="center">Yes</td>
<td align="center">Yes</td>
<td align="center">Yes</td>
<td align="center">Yes</td>
<td align="center">Yes</td>
<td align="center">Yes</td>
</tr>
<tr>
<th align="center">Latency,<br/>QoS Req.</th>
<td align="center">Yes</td>
<td align="center">Yes</td>
<td align="center">Yes</td>
<td align="center">Yes</td>
<td align="center">Yes</td>
<td align="center">Yes</td>
</tr>
<tr>
<th align="center">Frequent<br/>Tx Req.</th>
<td align="center">No</td>
<td align="center">No</td>
<td align="center">No</td>
<td align="center">Yes</td>
<td align="center">No</td>
<td align="center">No</td>
</tr>
<tr>
<th align="center">RFC</th>
<td align="center">RFC&nbsp;7428</td>
<td align="center">RFC 7668<br/>RFC 9159</td>
<td align="center">RFC&nbsp;8105</td>
<td align="center">RFC 8163</td>
<td align="center">RFC 9428</td>
<td align="center">RFC 9354</td>
</tr>
</tbody>
</table>
]]></artwork>
</section> </section>
</section> </section>
<!-- Section 3 - Guidelines for adopting IPv6 stack (6lo)-->
<section numbered="true" toc="default"> <section numbered="true" toc="default">
<name>Guidelines for adopting an IPv6 stack (6lo)</name> <name>Guidelines for Adopting an IPv6 Stack (6lo)</name>
<t>6lo aims at reusing and/or adapting existing 6LoWPAN functionality in o <t>6lo aims to reuse and/or adapt existing 6LoWPAN functionality in
rder to efficiently support IPv6 over a variety of IoT L2 technologies. The foll order to efficiently support IPv6 over a variety of IoT L2
owing guideline targets new candidate constrained L2 technologies that may be co technologies. The following guideline targets new candidate-constrained
nsidered for running a modified 6LoWPAN stack on top. The modification of the 6L L2 technologies that may be considered for running a modified 6LoWPAN
oWPAN stack should be based on the following:</t> stack on top. The modification of the 6LoWPAN stack should be based on
<ul spacing="normal"> the following:</t>
<li>Addressing Model: The addressing model determines whether the device <dl spacing="normal" newline="true">
is capable of forming IPv6 link-local and global addresses, and what is the bes <dt>Addressing Model:</dt>
t way to derive the IPv6 addresses for the constrained L2 devices. L2-address-de <dd>The addressing model determines whether the device is capable of
rived IPv6 addresses are specified in <xref target="RFC4944" format="default"/>, forming IPv6 link-local and global addresses, and what is the best way
but there exist implications for privacy. The reason is that the L2-address in to derive the IPv6 addresses for the constrained L2
6lo link layer technologies is a little short and devices can become vulnerable devices. IPv6 addresses that are derived from an L2 address are specified
to the various threats. For global usage, a unique IPv6 address must be derived in <xref
using an assigned prefix and a unique interface ID. <xref target="RFC8065" forma target="RFC4944" format="default"/>, but there are implications for
t="default"/> provides such guidelines. For MAC-derived IPv6 addresses, please r privacy. The reason is that the L2 address in 6lo link-layer
efer to <xref target="RFC8163" format="default"/> for IPv6 address mapping examp technologies is a little short, and devices can become vulnerable to
les. Broadcast and multicast support are dependent on the L2 networks. Most low- the various threats. For global usage, a unique IPv6 address must be
power L2 implementations map multicast to broadcast networks. So care must be ta derived using an assigned prefix and a unique interface ID. <xref
ken in the design for when to use broadcast, trying to stick to unicast messagin target="RFC8065" format="default"/> provides such guidelines. For
g whenever possible.</li> MAC-derived IPv6 addresses, refer to <xref target="RFC8163"
<li>MTU Considerations: The deployment should consider packet maximum tr format="default"/> for mapping examples. Broadcast and
ansmission unit (MTU) needs over the link layer and should consider if fragmenta multicast support are dependent on the L2 networks. Most low-power L2
tion and reassembly of packets are needed at the 6LoWPAN layer. For example, if implementations map multicast to broadcast networks. So care must be
the link layer supports fragmentation and reassembly of packets, then the 6LoWPA taken in the design for when to use broadcast, trying to stick to
N layer may not need to support fragmentation/reassembly. In fact, for greatest unicast messaging whenever possible.</dd>
efficiency, choosing a low-power link layer that can carry unfragmented applicat <dt>MTU Considerations:</dt>
ion packets would be optimal for packet transmission if the deployment can affor <dd>The deployment should consider packet maximum transmission unit
d it. Please refer to 6lo RFCs <xref target="RFC7668" format="default"/>, <xref (MTU) needs over the link layer and should consider if fragmentation
target="RFC8163" format="default"/>, and <xref target="RFC8105" format="default" and reassembly of packets are needed at the 6LoWPAN layer. For
/> for example guidance.</li> example, if the link layer supports fragmentation and reassembly of
<li>Mesh or L3-Routing: 6LoWPAN specifications provide mechanisms to sup packets, then the 6LoWPAN layer may not need to support fragmentation
port mesh routing at L2, a configuration called mesh-under <xref target="RFC6606 and reassembly. In fact, for greatest efficiency, choosing a low-power
" format="default"/>. It is also possible to use an L3 routing protocol in 6LoWP link layer that can carry unfragmented application packets would be
AN, an approach known as route-over. <xref target="RFC6550" format="default"/> d optimal for packet transmission if the deployment can afford
efines RPL, a L3 routing protocol for low power and lossy networks using directe it. Please refer to 6lo RFCs <xref target="RFC7668"
d acyclic graphs. 6LoWPAN is routing-protocol-agnostic and does not specify any format="default"/>, <xref target="RFC8163" format="default"/>, and
particular L2 or L3 routing protocol to use with a 6LoWPAN stack.</li> <xref target="RFC8105" format="default"/> for example guidance.</dd>
<li>Address Assignment: 6LoWPAN developed a new version of IPv6 Neighbor <dt>Mesh or L3 Routing:</dt>
Discovery <xref target="RFC4861" format="default"/><xref target="RFC4862" forma <dd>6LoWPAN specifications provide mechanisms to support mesh routing
t="default"/>. 6LoWPAN Neighbor Discovery <xref target="RFC6775" format="default at L2, a configuration called "mesh-under" <xref target="RFC6606"
"/><xref target="RFC8505" format="default"/> inherits from IPv6 Neighbor Discove format="default"/>. It is also possible to use an L3 routing protocol
ry for mechanisms such as Stateless Address Autoconfiguration (SLAAC) and Neighb in 6LoWPAN, an approach known as "route-over". <xref target="RFC6550"
or Unreachability Detection (NUD). A 6LoWPAN node is also expected to be an IPv6 format="default"/> defines RPL, an L3 routing protocol for low-power and
host per <xref target="RFC8200" format="default"/> which means it should ignore lossy networks
consumed routing headers and Hop-by-Hop options; when operating in a RPL networ using directed acyclic graphs. 6LoWPAN is routing-protocol-agnostic
k <xref target="RFC6550" format="default"/>, it is also beneficial to support IP and does not specify any particular L2 or L3 routing protocol to use
-in-IP encapsulation <xref target="RFC9008" format="default"/>. The 6LoWPAN node with a 6LoWPAN stack.</dd>
should also support <xref target="RFC8505" format="default"/> and use it as the <dt>Address Assignment:</dt>
default Neighbor Discovery method. It is the responsibility of the deployment t <dd>6LoWPAN developed a new version of IPv6 Neighbor Discovery <xref
o ensure unique global IPv6 addresses for Internet connectivity. For local-only target="RFC4861" format="default"/> <xref target="RFC4862"
connectivity IPv6 Unique Local Address (ULA) may be used. <xref target="RFC6775" format="default"/>. 6LoWPAN Neighbor Discovery <xref target="RFC6775"
format="default"/><xref target="RFC8505" format="default"/> specifies the 6LoWP format="default"/> <xref target="RFC8505" format="default"/> inherits
AN border router (6LBR), which is responsible for prefix assignment to the 6LoWP from IPv6 Neighbor Discovery for mechanisms such as Stateless Address
AN network. A 6LBR can be connected to the Internet or to an enterprise network Autoconfiguration (SLAAC) and Neighbor Unreachability Detection
via one of the interfaces. Please refer to <xref target="RFC7668" format="defaul (NUD). A 6LoWPAN node is also expected to be an IPv6 host per <xref
t"/> and <xref target="RFC8105" format="default"/> for examples of address assig target="RFC8200" format="default"/>, which means it should ignore
nment considerations. In addition, privacy considerations <xref target="RFC8065" consumed routing headers and hop-by-hop options. When operating in an
format="default"/> must be consulted for applicability. In certain scenarios, t RPL network <xref target="RFC6550" format="default"/>, it is also
he deployment may not support IPv6 address autoconfiguration due to regulatory a beneficial to support IP-in-IP encapsulation <xref target="RFC9008"
nd business reasons and may choose to offer a separate address assignment servic format="default"/>. The 6LoWPAN node should
e. Address Protection for 6LoWPAN Neighbor Discovery (AP-ND) <xref target="RFC89 also support the registration extensions defined in <xref target="RFC8505"
28" format="default"/> enables Source Address Validation <xref target="RFC6620" format="default"/> and use the mechanism as the default Neighbor Discovery meth
format="default"/> and protects the address ownership against impersonation atta od. It is the responsibility of
cks. the deployment to ensure unique global IPv6 addresses for Internet
</li> connectivity. For local-only connectivity, IPv6 Unique Local Address
<li>Broadcast Avoidance: 6LoWPAN Neighbor Discovery aims at reducing the (ULA) may be used. <xref target="RFC6775" format="default"/> and <xref
amount of multicast traffic of classical Neighbor Discovery, since IP-level mul target="RFC8505" format="default"/> specify the 6LoWPAN Border Router
ticast translates into L2 broadcast in many L2 technologies <xref target="RFC677 (6LBR), which is responsible for prefix assignment to the 6LoWPAN
5" format="default"/>. 6LoWPAN Neighbor Discovery relies on a proactive registra network. A 6LBR can be connected to the Internet or to an enterprise
tion to avoid the use of multicast for address resolution. It also uses a unicas network via one of the interfaces. Please refer to <xref
t method for Duplicate Address Detection (DAD), and avoids multicast lookups fro target="RFC7668" format="default"/> and <xref target="RFC8105"
m all nodes by using non-onlink prefixes. Router Advertisements (RAs) are also s format="default"/> for examples of address assignment
ent in unicast, in response to Router Solicitations (RSs)</li> considerations. In addition, privacy considerations in <xref
<li>Host-to-Router interface: 6lo has defined registration extensions fo target="RFC8065" format="default"/> must be consulted for
r 6LoWPAN Neighbor Discovery <xref target="RFC8505" format="default"/>. This eff applicability. In certain scenarios, the deployment may not support
ort provides a host-to-router interface by which a host can request its router t IPv6 address autoconfiguration due to regulatory and business reasons
o ensure reachability for the address registered with the router. Note that func and may choose to offer a separate address assignment service.
tionality has been developed to ensure that such a host can benefit from routing Address-Protected Neighbor Discovery
services in a RPL network <xref target="RFC9010" format="default"/></li> <xref target="RFC8928" format="default"/> enables source address
<li>Proxy Neighbor Discovery: Further functionality also allows a device validation <xref target="RFC6620" format="default"/> and protects the
(e.g., an energy-constrained device that needs to sleep most of the time) to re address ownership against impersonation attacks.</dd>
quest proxy Neighbor Discovery services from a 6LoWPAN Backbone Router (6BBR) <x <dt>Broadcast Avoidance:</dt>
ref target="RFC8505" format="default"/><xref target="RFC8929" format="default"/> <dd>6LoWPAN Neighbor Discovery aims to reduce the amount of
. The latter RFC federates a number of links into a multilink subnet. </li> multicast traffic of classic Neighbor Discovery, since IP-level
<li>Header Compression: IPv6 header compression <xref target="RFC6282" f multicast translates into L2 broadcast in many L2 technologies <xref
ormat="default"/> is a vital part of IPv6 over low power communication. Examples target="RFC6775" format="default"/>. 6LoWPAN Neighbor Discovery relies
of header compression over different link-layer specifications are found in <xr on a proactive registration to avoid the use of multicast for address
ef target="RFC7668" format="default"/>, <xref target="RFC8163" format="default"/ resolution. It also uses a unicast method for Duplicate Address
>, and <xref target="RFC8105" format="default"/>. A generic header compression t Detection (DAD) and avoids multicast lookups from all nodes by using
echnique is specified in <xref target="RFC7400" format="default"/>. For 6LoWPAN non-onlink prefixes. Router Advertisements (RAs) are also sent in
networks where RPL is the routing protocol, there exist 6LoWPAN header compressi unicast, in response to Router Solicitations (RSs).</dd>
on extensions which allow also compressing the RPL artifacts used when forwardin <dt>Host-to-Router Interface:</dt>
g packets in the route-over mesh <xref target="RFC8138" format="default"/> <xref <dd>6lo has defined registration extensions for 6LoWPAN Neighbor
target="RFC9035" format="default"/>.</li> Discovery <xref target="RFC8505" format="default"/>. This effort
<li>Security and Encryption: Though 6LoWPAN basic specifications do not provides a host-to-router interface by which a host can request its
address security at the network layer, the assumption is that L2 security must b router to ensure reachability for the address registered with the
e present. Nevertheless, care must be taken since specific L2 technologies may e router. Note that functionality has been developed to ensure that such
xhibit security gaps. Typically, 6lo L2 technologies (see Section 2) offer secur a host can benefit from routing services in a RPL network <xref
ity properties such as confidentiality and/or message authentication. In additio target="RFC9010" format="default"/>.</dd>
n, end-to-end security is highly desirable. Protocols such as DTLS/TLS, as well <dt>Proxy Neighbor Discovery:</dt>
as object security are being used in the constrained-node network domain <xref t <dd>Further functionality also allows a device (e.g., an
arget="I-D.ietf-lwig-security-protocol-comparison" format="default"/>. The relev energy-constrained device that needs to sleep most of the time) to
ant IETF working groups should be consulted for application and transport level request proxy Neighbor Discovery services from a 6LoWPAN Backbone
security. The IETF has worked on address authentication <xref target="RFC8928" f Router (6BBR) <xref target="RFC8505" format="default"/> <xref
ormat="default"/> and secure bootstrapping is also being discussed in the IETF. target="RFC8929" format="default"/>. The latter RFC federates a number
However, there may be other security mechanisms available in a deployment throug of links into a multi-link subnet. </dd>
h other standards such as hardware-level security or certificates for the initia <dt>Header Compression:</dt>
l booting process. In order to use security mechanisms, the implementation needs <dd>IPv6 header compression <xref target="RFC6282" format="default"/>
to afford it in terms of processing capabilities and energy consumption.</li> is a vital part of IPv6 over low-power communication. Examples of
<li>Additional processing: <xref target="RFC8066" format="default"/> def header compression over different link-layer specifications are found
ines guidelines for ESC dispatch octets use in the 6LoWPAN header. The in <xref target="RFC7668" format="default"/>, <xref target="RFC8163"
ESC type is defined to use additional dispatch octets in the 6LoWPAN format="default"/>, and <xref target="RFC8105" format="default"/>. A
header. An implementation may take advantage of the ESC header to offer a dep generic header compression technique is specified in <xref
loyment specific processing of 6LoWPAN packets.</li> target="RFC7400" format="default"/>.
</ul>
For 6LoWPAN networks where RPL is
the routing protocol, there are 6LoWPAN header compression extensions
that allow compressing the RPL artifacts used when forwarding packets
in the route-over mesh <xref target="RFC8138" format="default"/> <xref
target="RFC9035" format="default"/>.</dd>
<dt>Security and Encryption:</dt>
<dd>Though 6LoWPAN basic specifications do not address security at the
network layer, the assumption is that L2 security must be
present. Nevertheless, care must be taken since specific L2
technologies may exhibit security gaps.
Typically, 6lo L2 technologies
(see <xref target="sec2"/>) offer security properties such as
confidentiality and/or message authentication. In addition, end-to-end
security is highly desirable. Protocols such as DTLS/TLS, as well as
Object Security, are being used in the constrained-node network domain
<xref target="I-D.ietf-iotops-security-protocol-comparison"
format="default"/>. The relevant IETF working groups should be
consulted for application and transport level security.
The IETF has
worked on address authentication <xref target="RFC8928"
format="default"/>, and secure bootstrapping is also being discussed in
the IETF. However, there may be other security mechanisms available in
a deployment through other standards, such as hardware-level security
or certificates for the initial booting process. In order to use
security mechanisms, the implementation needs to be able to afford it in
terms of
processing capabilities and energy consumption.</dd>
<dt>Additional Processing:</dt>
<dd><xref target="RFC8066" format="default"/> defines guidelines for
ESC dispatch octets used in the 6LoWPAN header. The ESC type is defined
to use additional dispatch octets in the 6LoWPAN header. An
implementation may take advantage of the ESC header to offer a
deployment-specific processing of 6LoWPAN packets.</dd>
</dl>
</section> </section>
<!-- Section 4 - 6lo Deployment Examples -->
<section numbered="true" toc="default"> <section numbered="true" toc="default">
<name>6lo Deployment Examples</name> <name>6lo Deployment Examples</name>
<!-- Section 4.1 -->
<section numbered="true" toc="default"> <section numbered="true" toc="default">
<name>Wi-SUN usage of 6lo in network layer</name> <name>Wi-SUN Usage of 6lo in Network Layer</name>
<t>Wireless Smart Ubiquitous Network (Wi-SUN) <xref target="Wi-SUN" form <t>Wireless Smart Ubiquitous Network (Wi-SUN) <xref target="Wi-SUN"
at="default"/> is a technology based on IEEE Std 802.15.4g. Wi-SUN networks supp format="default"/> is a technology based on IEEE Std 802.15.4g <xref tar
ort star and mesh topologies, as well as hybrid star/mesh deployments, but these get="IEEE-802.15.4" />. Wi-SUN
are typically laid out in a mesh topology where each node relays data for the n networks support star and mesh topologies as well as hybrid star/mesh
etwork to provide network connectivity. Wi-SUN networks are deployed on both gri deployments, but these are typically laid out in a mesh topology where
d-powered and battery-operated devices <xref target="RFC8376" format="default"/> each node relays data for the network to provide network
.</t> connectivity. Wi-SUN networks are deployed on both grid-powered and
<t> The main application domains using Wi-SUN are smart utility and smar battery-operated devices <xref target="RFC8376"
t city networks. The Wi-SUN Alliance Field Area Network (FAN) covers primarily o format="default"/>.</t>
utdoor networks. The Wi-SUN Field Area Network specification defines an IPv6-bas <t> The main application domains using Wi-SUN are smart utility and
ed protocol suite including TCP/UDP, IPv6, 6lo adaptation layer, DHCPv6 for IPv6 smart city networks. The Wi-SUN Alliance Field Area Network (FAN)
address management, RPL, and ICMPv6. </t> primarily covers outdoor networks. The Wi-SUN FAN specification
defines an IPv6-based protocol suite that includes TCP/UDP, IPv6, 6lo
adaptation layer, DHCPv6 for IPv6 address management, RPL, and
ICMPv6. </t>
</section> </section>
<!-- Section 4.2 -->
<section numbered="true" toc="default"> <section numbered="true" toc="default">
<name>Thread usage of 6lo in network layer</name> <name>Thread Usage of 6lo in the Network Layer</name>
<t>Thread is an IPv6-based networking protocol stack built on open stand <t>Thread is an IPv6-based networking protocol stack built on open
ards, designed for smart home environments, and based on low-power IEEE Std 802. standards, designed for smart home environments, and based on
15.4 mesh networks. Because of its IPv6 foundation, Thread can support existing low-power IEEE Std 802.15.4 mesh networks. Because of its IPv6
popular application layers and IoT platforms, provide end-to-end security, ease foundation, Thread can support existing popular application layers and
development and enable flexible designs <xref target="Thread" format="default"/> IoT platforms, provide end-to-end security, ease development, and
.</t> enable flexible designs <xref target="Thread" format="default"/>.</t>
<t>The Thread specification uses the IEEE Std 802.15.4 <xref target="IEE <t>The Thread specification uses the IEEE Std 802.15.4 <xref target="IEE
E802154" format="default"/> physical and MAC layers operating at 250 kbps in the E-802.15.4" format="default"/> physical and MAC layers operating at 250 kbps in
2.4 GHz band.</t> the 2.4 GHz band.</t>
<t>Thread devices use 6LoWPAN, as defined in <xref target="RFC4944" form <t>Thread devices use 6LoWPAN, as defined in <xref target="RFC4944" form
at="default"/><xref target="RFC6282" format="default"/>, for transmission of IPv at="default"/> and <xref target="RFC6282" format="default"/>, for transmission o
6 Packets over IEEE Std 802.15.4 networks. Header compression is used within the f IPv6 packets over IEEE Std 802.15.4 networks. Header compression is used withi
Thread network and devices transmitting messages compress the IPv6 header to mi n the Thread network, and devices transmitting messages compress the IPv6 header
nimize the size of the transmitted packet. The mesh header is supported for link to minimize the size of the transmitted packet. The mesh header is supported fo
-layer (i.e., mesh under) forwarding. The mesh header as used in Thread also all r link-layer (i.e., mesh-under) forwarding. The mesh header as used in Thread al
ows efficient end-to-end fragmentation of messages rather than the hop-by-hop fr so allows efficient end-to-end fragmentation of messages rather than the hop-by-
agmentation specified in <xref target="RFC4944" format="default"/>. Mesh under r hop fragmentation specified in <xref target="RFC4944" format="default"/>. Mesh-u
outing in Thread is based on a distance vector protocol in a full mesh topology. nder routing in Thread is based on a distance vector protocol in a full mesh top
</t> ology.</t>
</section> </section>
<!-- Section 4.3 -->
<section numbered="true" toc="default"> <section numbered="true" toc="default">
<name>G3-PLC usage of 6lo in network layer</name> <name>G3-PLC Usage of 6lo in Network Layer</name>
<t>G3-PLC <xref target="G3-PLC" format="default"/> is a narrowband PLC t <t>G3-PLC <xref target="G3-PLC" format="default"/> is a narrowband PLC
echnology that is based on the ITU-T G.9903 Recommendation <xref target="G.9903" technology that is based on the ITU-T G.9903 Recommendation <xref
format="default"/>. G3-PLC supports multi-hop mesh network topology, and facili target="G.9903" format="default"/>. G3-PLC supports multi-hop mesh
tates highly reliable, long-range communication. With the abilities to support I network topology and facilitates highly reliable, long-range
Pv6 and to cross transformers, G3-PLC is regarded as one of the next-generation communication. With the abilities to support IPv6 and to cross
narrowband PLC technologies. G3-PLC has got massive deployments over several cou transformers, G3-PLC is regarded as one of the next-generation
ntries, e.g., Japan and France. </t> narrowband PLC technologies. G3-PLC has got massive deployments over
<t> The main application domains using G3-PLC are smart grid and smart c several countries, e.g., Japan and France. </t>
ities. This includes, but is not limited to the following applications:</t> <t> The main application domains using G3-PLC are smart grid and smart
cities. This includes, but is not limited to, the following
applications:</t>
<ul spacing="normal"> <ul spacing="normal">
<li>Smart metering</li> <li>smart metering</li>
<li>Vehicle-to-grid communication</li> <li>vehicle-to-grid communication</li>
<li>Demand response</li> <li>demand response</li>
<li>Distribution automation</li> <li>distribution automation</li>
<li>Home/Building energy management systems</li> <li>home/building energy management systems</li>
<li>Smart street lighting</li> <li>smart street lighting</li>
<li> AMI backbone network</li> <li>AMI backbone network</li>
<li>Wind/Solar farm monitoring</li> <li>wind/solar farm monitoring</li>
</ul> </ul>
<t>In the G3-PLC specification, the 6lo adaption layer utilizes the 6LoW PAN functions (e.g., header compression, fragmentation and <t>In the G3-PLC specification, the 6lo adaption layer utilizes the 6LoW PAN functions (e.g., header compression, fragmentation, and
reassembly). However, due to the different characteristics of the PLC media, the 6LoWPAN adaptation layer cannot perfectly fulfill the requirements <xref target ="RFC9354" format="default"/>. The ESC dispatch type is used in the G3-PLC to pr ovide fundamental mesh routing and bootstrapping functionalities <xref target="R FC8066" format="default"/>.</t> reassembly). However, due to the different characteristics of the PLC media, the 6LoWPAN adaptation layer cannot perfectly fulfill the requirements <xref target ="RFC9354" format="default"/>. The ESC dispatch type is used in the G3-PLC to pr ovide fundamental mesh routing and bootstrapping functionalities <xref target="R FC8066" format="default"/>.</t>
</section> </section>
<!-- Section 4.4 -->
<section numbered="true" toc="default"> <section numbered="true" toc="default">
<name>Netricity usage of 6lo in network layer</name> <name>Netricity Usage of 6lo in the Network Layer</name>
<t>The Netricity program in the HomePlug Powerline Alliance <xref target <t>The Netricity program in the HomePlug Powerline Alliance <xref target
="NETRICITY" format="default"/> promotes the adoption of products built on the I ="NETRICITY" format="default"/> promotes the adoption of products built on the I
EEE Std 1901.2 low-frequency narrowband PLC standard, which provides for urban a EEE Std 1901.2 low-frequency narrowband PLC standard <xref target="IEEE-1901.2"/
nd long-distance communications and propagation through transformers of the dist >, which provides for urban and long-distance communications and propagation thr
ribution network using frequencies below 500 kHz. The technology also addresses ough transformers of the distribution network using frequencies below 500 kHz. T
requirements that assure communication privacy and secure networks. </t> he technology also addresses requirements that assure communication privacy and
<t> The main application domains using Netricity are smart grid and smar secure networks. </t>
t cities. This includes, but is not limited to the following applications:</t> <t> The main application domains using Netricity are smart grid and smar
t cities. This includes, but is not limited to, the following applications:</t>
<ul spacing="normal"> <ul spacing="normal">
<li>Utility grid modernization</li> <li>utility grid modernization</li>
<li>Distribution automation</li> <li>distribution automation</li>
<li>Meter-to-Grid connectivity</li> <li>meter-to-grid connectivity</li>
<li>Micro-grids</li> <li>microgrids</li>
<li>Grid sensor communications</li> <li>grid sensor communications</li>
<li>Load control</li> <li>load control</li>
<li>Demand response</li> <li>demand response</li>
<li>Net metering</li> <li>net metering</li>
<li>Street lighting control</li> <li>street lighting control</li>
<li>Photovoltaic panel monitoring</li> <li>photovoltaic panel monitoring</li>
</ul> </ul>
<t>The Netricity system architecture is based on the physical and MAC la
yers of IEEE Std 1901.2. Regarding the 6lo adaptation layer and an IPv6 network <t>The Netricity system architecture is based on the physical and MAC la
layer, Netricity utilizes IPv6 protocol suite including 6lo/6LoWPAN header compr yers of IEEE Std 1901.2. Regarding the 6lo adaptation layer and an IPv6 network
ession, DHCPv6 for IP address management, RPL routing protocol, ICMPv6, and unic layer, Netricity utilizes IPv6 protocol suite including 6lo/6LoWPAN header compr
ast/multicast forwarding. Note that the L3 routing in Netricity uses RPL in non- ession, DHCPv6 for IP address management, RPL routing protocol, ICMPv6, and unic
storing mode with the MRHOF (Minimum Rank with Hysteresis Objective Function) ob ast/multicast forwarding. Note that the L3 routing in Netricity uses RPL in non-
jective function based on their own defined Estimated Transmission Time (ETT) me storing mode with the MRHOF (Minimum Rank with Hysteresis Objective Function) ba
tric.</t> sed on their own defined Estimated Transmission Time (ETT) metric.</t>
</section> </section>
</section> </section>
<!-- Section 5 - 6lo Use Case Examples -->
<section numbered="true" toc="default"> <section numbered="true" toc="default">
<name>6lo Use Case Examples</name> <name>6lo Use-Case Examples</name>
<t>As IPv6 stacks for constrained node networks use a variation of the 6Lo <t>As IPv6 stacks for constrained-node networks use a variation of the 6Lo
WPAN stack applied to each particular link layer technology, various 6lo use cas WPAN stack applied to each particular link-layer technology, various 6lo use cas
es can be provided. In this section, various 6lo use cases which are based on di es can be provided. In this section, various 6lo use cases, which are based on d
fferent link layer technologies are described.</t> ifferent link-layer technologies, are described.</t>
<!-- Section 5.1 - Use case of ITU-T G.9959: Smart Home-->
<section numbered="true" toc="default"> <section numbered="true" toc="default">
<name>Use case of ITU-T G.9959: Smart Home</name> <name>Use Case of ITU-T G.9959: Smart Home</name>
<t> Z-Wave is one of the main technologies that may be used to enable sm <t> Z-Wave is one of the main technologies that may be used to enable sm
art home applications. Born as a proprietary technology, Z-Wave was specifically art home applications. Born as a proprietary technology, Z-Wave was specifically
designed for this particular use case. Recently, the Z-Wave radio interface (ph designed for this particular use case. Recently, the Z-Wave radio interface (ph
ysical and MAC layers) has been standardized as the ITU-T G.9959 specification. ysical and MAC layers) has been standardized as the ITU-T G.9959 specification <
</t> xref target="G.9959"/>. </t>
<t>Example: Use of ITU-T G.9959 for Home Automation </t> <t>Example: Use of ITU-T G.9959 for Home Automation</t>
<t>A variety of home devices (e.g., light dimmers/switches, plugs, therm <t indent="3">A variety of home devices (e.g., light dimmers/switches,
ostats, blinds/curtains, and remote controls) are augmented with ITU-T G.9959 in plugs,
terfaces. A user may turn on/off or may control home appliances by pressing a wa thermostats, blinds/curtains, and remote controls) are augmented
ll switch or by pressing a button in a remote control. Scenes may be programmed, with ITU-T G.9959 interfaces.
so that after a given event, the home devices adopt a specific configuration. S A user may turn home appliances on and off, or the user may control them
ensors may also periodically send measurements of several parameters (e.g., gas by pressing a wall switch or a button on a
presence, light, temperature, humidity) which are collected at a sink device, or remote control.
may generate commands for actuators (e.g., a smoke sensor may send an alarm mes Scenes may be programmed so that
sage to a safety system). </t> the home devices adopt a specific configuration after a given event. S
<t>The devices involved in the described scenario are nodes of a network ensors may
that follows the mesh topology, which is suitable for path diversity to face in also periodically send measurements of several parameters (e.g., gas
door multipath propagation issues. The multihop paradigm allows end-to-end conne presence, light, temperature, humidity), which are collected at a
ctivity when direct range communication is not possible.</t> sink device, or may generate commands for actuators (e.g., a smoke
sensor may send an alarm message to a safety system).</t>
<t>The devices involved in the described scenario are nodes of a network
that follows the mesh topology, which is suitable for path diversity to face in
door multipath propagation issues. The multi-hop paradigm allows end-to-end conn
ectivity when direct range communication is not possible.</t>
</section> </section>
<!-- Section 5.2 - Use case of Bluetooth LE: Smartphone-based Interaction -->
<section numbered="true" toc="default"> <section numbered="true" toc="default">
<name>Use case of Bluetooth LE: Smartphone-based Interaction</name> <name>Use Case of Bluetooth LE: Smartphone-Based Interaction</name>
<t>The key feature behind the current high Bluetooth LE momentum is its <t>The key feature behind the current high Bluetooth LE momentum is its
support in a large majority of smartphones in the market. Bluetooth LE can be us support in a large majority of smartphones in the market. Bluetooth LE can be us
ed to allow the interaction between the smartphone and surrounding sensors or ac ed to allow interaction between a smartphone and surrounding sensors or actuator
tuators. Furthermore, Bluetooth LE is also the main radio interface currently av s. Furthermore, Bluetooth LE is also the main radio interface currently availabl
ailable in wearables. Since a smartphone typically has several radio interfaces e in wearables. Since a smartphone typically has several radio interfaces that p
that provide Internet access, such as Wi-Fi or cellular, the smartphone can act rovide Internet access, such as Wi-Fi or cellular, a smartphone can act as a gat
as a gateway for nearby devices such as sensors, actuators or wearables. Bluetoo eway for nearby devices, such as sensors, actuators, or wearables. Bluetooth LE
th LE may be used in several domains, including healthcare, sports/wellness, and may be used in several domains, including healthcare, sports/wellness, and home
home automation. </t> automation. </t>
<t>Example: Use of Bluetooth LE-based Body Area Network for fitness</t> <t>Example: Use of a Body Area Network Based on Bluetooth LE for Fitness
<t>A person wears a smartwatch for fitness purposes. The smartwatch has </t>
several sensors (e.g., heart rate, accelerometer, gyrometer, GPS, temperature), <t indent="3">A person wears a smartwatch for fitness purposes. The smar
a display, and a Bluetooth LE radio interface. The smartwatch can show fitness-r twatch
elated statistics on its display. However, when a paired smartphone is in the ra has several sensors (e.g., heart rate, accelerometer, gyrometer, GPS,
nge of the smartwatch, the latter can report almost real-time measurements of it and temperature), a display, and a Bluetooth LE radio interface. The
s sensors to the smartphone, which can forward the data to a cloud service on th smartwatch can show fitness-related statistics on its
e Internet. 6lo enables this use case by providing efficient end-to-end IPv6 sup display. However, when a paired smartphone is in range of the
port. In addition, the smartwatch can receive notifications (e.g., alarm signals smartwatch, the latter can report almost real-time measurements of its
) from the cloud service via the smartphone. On the other hand, the smartphone m sensors to the smartphone, which can forward the data to a cloud
ay locally generate messages for the smartwatch, such as e-mail reception or cal service on the Internet. 6lo enables this use case by providing
endar notifications. </t> efficient end-to-end IPv6 support. In addition, the smartwatch can
<t> The functionality supported by the smartwatch may be complemented by receive notifications (e.g., alarm signals) from the cloud service via
other devices such as other on-body sensors, wireless headsets or head-mounted the smartphone. On the other hand, the smartphone may locally generate
displays. All such devices may connect to the smartphone creating a star topolog messages for the smartwatch, such as e-mail reception or calendar
y network whereby the smartphone is the central component. Support for extended notifications.</t>
network topologies (e.g., mesh networks) is being developed as of the writing.</
t> <t> The functionality supported by the smartwatch may be complemented by
other devices, such as other on-body sensors, wireless headsets, or head-mounte
d displays. All such devices may connect to the smartphone, creating a star topo
logy network whereby the smartphone is the central component. Support for extend
ed network topologies (e.g., mesh networks) is being developed as of the writing
of this document.</t>
</section> </section>
<!-- Section 5.3 Use case of DECT-ULE: Smart Home -->
<section numbered="true" toc="default"> <section numbered="true" toc="default">
<name>Use case of DECT-ULE: Smart Home</name> <name>Use Case of DECT-ULE: Smart Home</name>
<t>DECT is a technology widely used for wireless telephone communication <t>DECT is a technology widely used for wireless telephone
s in residential scenarios. Since DECT-ULE is a low-power variant of DECT, DECT- communications in residential scenarios. Since DECT-ULE is a low-power
ULE can be used to connect constrained devices such as sensors and actuators to variant of DECT, DECT-ULE can be used to connect constrained devices
a Fixed Part, a device that typically acts as a base station for wireless teleph (such as sensors and actuators) to a Fixed Part (FP), a device that
ones. In this case, additionally, the Fixed Part must have a data network connec typically acts as a base station for wireless telephones. In this
tion. Therefore, DECT-ULE is especially suitable for the connected home space in case, additionally, the FP must have a data network
application areas such as home automation, smart metering, safety, and healthca connection. Therefore, DECT-ULE is especially suitable for the
re. Since DECT-ULE uses dedicated bandwidth, it avoids this coexistence issues s connected home space in application areas such as home automation,
uffered by other technologies that use e.g., ISM frequency bands.</t> smart metering, safety, and healthcare. Since DECT-ULE uses dedicated
<t>Example: Use of DECT-ULE for Smart Metering </t> bandwidth, it avoids this coexistence issues suffered by other
<t>The smart electricity meter of a home is equipped with a DECT-ULE tra technologies that use, for example, Industrial, Scientific, and Medical
nsceiver. This device is in the coverage range of the Fixed Part of the home. Th (ISM) frequency bands.</t>
e Fixed Part can act as a router connected to the Internet. This way, the smart <t>Example: Use of DECT-ULE for Smart Metering</t>
meter can transmit electricity consumption readings through the DECT-ULE link wi <t indent="3">The smart electricity meter of a home is equipped with a D
th the Fixed Part, and the latter can forward such readings to the utility compa ECT-ULE
ny using Wide Area Network (WAN) links. The meter can also receive queries from transceiver. This device is in the coverage range of the FP of
the utility company or from an advanced energy control system controlled by the the home. The FP can act as a router connected to the
user, which may also be connected to the Fixed Part via DECT-ULE. </t> Internet. This way, the smart meter can transmit electricity
consumption readings through the DECT-ULE link with the FP,
and the latter can forward such readings to the utility company using
Wide Area Network (WAN) links. The meter can also receive queries from
the utility company or from an advanced energy control system
controlled by the user, which may also be connected to the FP
via DECT-ULE.</t>
</section> </section>
<!-- Section 5.4 Use case of MS/TP: Building Automation Networks -->
<section numbered="true" toc="default"> <section numbered="true" toc="default">
<name>Use case of MS/TP: Building Automation Networks</name> <name>Use Case of MS/TP: Building Automation Networks</name>
<t> The primary use case for IPv6 over MS/TP (6LoBAC) is in building aut <t> The primary use case for IPv6 over MS/TP (6LoBAC) is in building aut
omation networks. <xref target="BACnet" format="default"/> is the open, internat omation networks. <xref target="BACnet" format="default"/> is the open, internat
ional standard protocol for building automation, and MS/TP is defined in <xref ional standard protocol for building automation, and MS/TP is defined in <xref
target="BACnet" format="default"/> Clause 9. MS/TP was designed to be a low-cos target="BACnet" format="default"/> Clause 9. MS/TP was designed to be a low-cos
t, multi-drop field bus to interconnect the most numerous elements (sensors and t, multi-drop field bus to interconnect the most numerous elements (sensors and
actuators) of a building automation network to their controllers. A key aspect actuators) of a building automation network to their controllers. A key aspect
of 6LoBAC is that it is designed to co-exist with BACnet MS/TP on the same link, of 6LoBAC is that it is designed to co-exist with BACnet MS/TP on the same link,
easing the ultimate transition of some BACnet networks to fundamental end-to-en easing the ultimate transition of some BACnet networks to fundamental end-to-en
d IPv6 transport protocols. New applications for 6LoBAC may be found in other do d IPv6 transport protocols. New applications for 6LoBAC may be found in other do
mains where low cost, long distance, and low latency are required. Note that BAC mains where low cost, long distance, and low latency are required. Note that BAC
net comprises various networking solutions other than MS/TP, including the recen net comprises various networking solutions other than MS/TP, including the recen
tly emerged BACnet IP. However, the latter is based on high-speed Ethernet infra tly emerged BACnet IP. However, the latter is based on high-speed Ethernet infra
structure, and it is outside of the constrained node network scope.</t> structure, and it is outside of the constrained-node network scope.</t>
<t>Example: Use of 6LoBAC in Building Automation Networks </t>
<t>The majority of installations for MS/TP are for "terminal" or "unitar <t>Example: Use of 6LoBAC in Building Automation Networks</t>
y" controllers, i.e., single zone or room controllers that may connect to HVAC o <t indent="3">The majority of installations for MS/TP are for "terminal"
r other controls such as lighting or blinds. The economics of daisy-chaining a s or
ingle twisted-pair between multiple devices is often preferred over home-run, Ca "unitary" controllers, i.e., single zone or room controllers that may
t 5-style wiring.</t> connect to HVAC or other controls such as lighting or blinds. The
economics of daisy chaining a single twisted pair between multiple
devices is often preferred over home-run, Cat-5-style wiring.</t>
<t> A multi-zone controller might be implemented as an IP router between a classical Ethernet link and several 6LoBAC links, fanning out to multiple ter minal controllers.</t> <t> A multi-zone controller might be implemented as an IP router between a classical Ethernet link and several 6LoBAC links, fanning out to multiple ter minal controllers.</t>
<t>The superior distance capabilities of MS/TP (~1 km) compared to other 6lo media may suggest its use in applications to connect remote devices to the nearest building infrastructure. For example, remote pumping or measuring statio ns with moderate bandwidth requirements can benefit from the low-cost and robust capabilities of MS/TP over other wired technologies such as DSL, and without th e line-of-sight restrictions or hop-by-hop latency of many low-cost wireless sol utions.</t> <t>The superior distance capabilities of MS/TP (~1 km) compared to other 6lo media may suggest its use in applications to connect remote devices to the nearest building infrastructure. For example, remote pumping or measuring statio ns with moderate bandwidth requirements can benefit from the low-cost and robust capabilities of MS/TP over other wired technologies such as DSL, without the li ne-of-sight restrictions or hop-by-hop latency of many low-cost wireless solutio ns.</t>
</section> </section>
<!-- Section 5.5 Use case of NFC: Alternative Secure Transfer -->
<section numbered="true" toc="default"> <section numbered="true" toc="default">
<name>Use case of NFC: Alternative Secure Transfer</name> <name>Use Case of NFC: Alternative Secure Transfer</name>
<t>In different applications, a variety of secured data can be handled a nd transferred. Depending on the security level of the data, different transfer methods can be alternatively selected.</t> <t>In different applications, a variety of secured data can be handled a nd transferred. Depending on the security level of the data, different transfer methods can be alternatively selected.</t>
<t>Example: Use of NFC for Secure Transfer in Healthcare Services with T
ele-Assistance </t> <t>Example: Use of NFC for Secure Transfer in Healthcare Services with
<t>A senior citizen who lives alone wears one to several wearable 6lo de Tele-Assistance </t>
vices to measure heartbeat, pulse rate. Other 6lo devices are densely installed <t indent="3">An older adult who lives alone wears one to several wearab
at home for movement detection. A 6LBR at home will send the sensed information le
to a connected healthcare center. Portable base stations with displays may be us 6lo devices to measure heartbeat, pulse rate, etc. Other 6lo devices
ed to check the data at home, as well. Data is gathered in both periodic and eve are densely installed at home for movement detection. A 6LBR at home
nt-driven fashion. In this application, event-driven data can be very time-criti will send the sensed information to a connected healthcare
cal. In addition, privacy also becomes a serious issue in this case, as the sens center. Portable base stations with displays may be used to check the
ed data is very personal.</t> data at home, as well. Data is gathered in both periodic and
<t>While the senior citizen is provided audio and video healthcare servi event-driven fashion. In this application, event-driven data can be
ces by a tele-assistance based on cellular connections, the senior citizen can a very time critical. In addition, privacy becomes a serious issue
lternatively use NFC connections to transfer the personal sensed data to the tel in this case, as the sensed data is very personal.</t>
e-assistance. Hackers can overhear the data based on the cellular connection, bu
t they cannot gather the personal data over the NFC connection.</t> <t>While the older adult is provided audio and video healthcare services
by a tele-assistance based on cellular connections, the older adult can alterna
tively use NFC connections to transfer the personal sensed data to the tele-assi
stance. Hackers can overhear the data based on the cellular connection, but they
cannot gather the personal data over the NFC connection.</t>
</section> </section>
<!-- Section 5.6 Use case of PLC: Smart Grid -->
<section numbered="true" toc="default"> <section numbered="true" toc="default">
<name>Use case of PLC: Smart Grid</name> <name>Use Case of PLC: Smart Grid</name>
<t>The smart grid concept is based on deploying numerous operational and <t>The smart grid concept is based on deploying numerous operational and
energy measuring sub-systems in an electricity grid system. It comprises multip energy measuring subsystems in an electricity grid system. It comprises multipl
le administrative levels/segments to provide connectivity among these numerous c e administrative levels and segments to provide connectivity among these numerou
omponents. Last mile connectivity is established over the Low Voltage segment, s components. Last mile connectivity is established over the Low-Voltage segmen
whereas connectivity over electricity distribution takes place in the High Volta t, whereas connectivity over electricity distribution takes place over the High-
ge segment. Smart grid systems include AMI, Demand Response, Home Energy Managem Voltage segment. Smart grid systems include AMI, Demand Response, Home Energy Ma
ent System, Wide Area Situational Awareness (WASA), among others.</t> nagement System, and Wide Area Situational Awareness (WASA), among others.</t>
<t>Although other wired and wireless technologies are also used in Smart
Grid, PLC enjoys the advantage of reliable data communication over electrical p <t>
ower lines that are already present, and the deployment cost can be comparable t Although other wired and wireless technologies are also used in a
o wireless technologies. The 6lo-related scenarios for PLC mainly lie in the LV smart grid, PLC benefits from reliable data
PLC networks with most applications in the area of advanced metering infrastruct communication over electrical power lines that are already present,
ure, vehicle-to-grid communications, in-home energy management, and smart street and the deployment cost can be comparable to wireless technologies.
lighting.</t> The 6lo-related scenarios for PLC mainly lie in the Low-Voltage PLC networks wit
h most applications in the area of advanced metering infrastructure, vehicle-to-
grid communications, in-home energy management, and smart street lighting.</t>
<t>Example: Use of PLC for AMI</t> <t>Example: Use of PLC for AMI</t>
<t>Household electricity meters transmit time-based data of electric <t indent="3">Household electricity meters transmit time-based data of e
power consumption through PLC. Data concentrators receive lectric
all the power consumption through PLC. Data concentrators receive all the
meter data in their corresponding living districts and se meter data in their corresponding living districts and send them to
nd them to the Meter Data Management System through a WAN network (e.g.,
the Meter Data Management System through a WAN network Medium-Voltage PLC, Ethernet, or General Packet Radio Service (GPRS)) fo
(e.g., Medium-Voltage PLC, Ethernet, or GPRS) for storage r storage and analysis.
and analysis. Two-way communications are enabled, which means smart meters can
Two-way communications are enabled which means smart mete perform actions like notification of electricity charges according to
rs can do the commands from the utility company.</t>
actions like notification of electricity charges accordin
g to the <t>With the existing power line infrastructure as a communication
commands from the utility company.</t> medium, the cost of building up the PLC network is naturally saved, and
<t>With the existing power line infrastructure as communication medium, more importantly, labor and operational costs can be minimized from a
cost on building up the PLC network is naturally saved, a long-term perspective. Furthermore, this AMI application speeds up
nd more electricity charging, reduces losses by restraining power theft, and
importantly, labor and operational costs can be minimized helps to manage the health of the grid based on line loss
from a long-term analysis.</t>
perspective. Furthermore, this AMI application speeds up
electricity <t>Example: Use of PLC (IEEE Std 1901.1) for WASA in a Smart Grid</t>
charging, reduces losses by restraining power theft, and <t indent="3">Many subsystems of a smart grid require low data rates, an
helps to manage d
the health of the grid based on line loss analysis.</t> narrowband variants (e.g., IEEE Std 1901.1) of PLC fulfill such
<t>Example: Use of PLC (IEEE Std 1901.1) for WASA in Smart Grid</t> requirements. Recently, more complex scenarios are emerging that
<t>Many sub-systems of Smart Grid require low data rates, and require higher data rates.</t>
narrowband variants (e.g., IEEE Std 1901.1) of PLC fulfill such r
equirements. <t>A WASA subsystem is an appropriate example that collects large
Recently, more complex scenarios are emerging that require higher amounts of information about the current state of the grid over a wide
data area from electric substations as well as power transmission
rates.</t> lines. The collected feedback is used for monitoring, controlling, and
<t>A WASA sub-system is an appropriate example that collects large amoun protecting all the subsystems.</t>
ts
of information about the current state of the grid over a wide ar
ea from
electric substations as well as power transmission lines. The col
lected
feedback is used for monitoring, controlling, and protecting all
the
sub-systems.</t>
</section> </section>
</section> </section>
<!-- Section 6 - IANA Consideration -->
<section anchor="IANA" numbered="true" toc="default"> <section anchor="IANA" numbered="true" toc="default">
<name>IANA Considerations</name> <name>IANA Considerations</name>
<t>There are no IANA considerations related to this document.</t> <t>This document has no IANA actions.</t>
</section> </section>
<!-- Section 7 - Security Considerations -->
<section numbered="true" toc="default"> <section numbered="true" toc="default">
<name>Security Considerations</name> <name>Security Considerations</name>
<t> This document does not create security concerns in addition to those <t> This document does not create security concerns in addition to those
described in the Security Considerations sections of the 6lo adaptation layers described in the Security Considerations sections of the 6lo adaptation layers
considered in this document <xref target="RFC7428" format="default"/>, <xref tar considered in this document <xref target="RFC7428" format="default"/>, <xref tar
get="RFC7668" format="default"/>, <xref target="RFC8105" format="default"/>, <xr get="RFC7668" format="default"/>, <xref target="RFC8105" format="default"/>, <xr
ef target="RFC8163" format="default"/>, <xref target="RFC9159" format="default"/ ef target="RFC8163" format="default"/>, <xref target="RFC9159" format="default"/
>, <xref target="I-D.ietf-6lo-nfc" format="default"/>, and <xref target="RFC9354 >, <xref target="RFC9428" format="default"/>, and <xref target="RFC9354" format=
" format="default"/>.</t> "default"/>.</t>
<t>Neighbor Discovery in 6lo links may be susceptible to threats as detail <t>Neighbor Discovery in 6lo links may be susceptible to threats as detail
ed in <xref target="RFC3756" format="default"/>. Mesh routing is expected to be ed in <xref target="RFC3756" format="default"/>. Mesh routing is expected to be
common in some 6lo networks, such as ITU-T G.9959 networks, BLE mesh networks an common in some 6lo networks, such as ITU-T G.9959 networks, Bluetooth LE mesh ne
d PLC networks. This implies additional threats due to ad hoc routing as per <xr tworks, and PLC networks. This implies additional threats due to ad hoc routing
ef target="KW03" format="default"/>. Most of the L2 technologies considered in t as per <xref target="KW03" format="default"/>. Most of the L2 technologies consi
his document (i.e., ITU-T G.9959, BLE, DECT-ULE, and PLC) support link-layer sec dered in this document (i.e., ITU-T G.9959, Bluetooth LE, DECT-ULE, and PLC) sup
urity. Making use of such provisions will alleviate the threats mentioned above. port link-layer security. Making use of such provisions will alleviate the threa
Note that NFC is often considered to offer intrinsic security properties due to ts mentioned above. Note that NFC is often considered to offer intrinsic securit
its short link range. MS/TP does not support link-layer security, since in its y properties due to its short link range. MS/TP does not support link-layer secu
original BACnet protocol stack, security is provided at the network layer; thus, rity, since in its original BACnet protocol stack, security is provided at the n
alternative security functionality needs to be used for a 6lo-based protocol st etwork layer; thus, alternative security functionality needs to be used for a 6l
ack over MS/TP.</t> o-based protocol stack over MS/TP.</t>
<t>End-to-end communication is expected to be secured by means of common m <t>End-to-end communication is expected to be secured by means of common m
echanisms, such as IPsec, TLS/DTLS, object security <xref target="RFC8613" forma echanisms, such as IPsec, DTLS/TLS, Object Security <xref target="RFC8613" forma
t="default"/>, and EDHOC(Ephemeral Diffie-Hellman Over COSE) <xref target="I-D.i t="default"/>, and Ephemeral Diffie-Hellman Over COSE (EDHOC) <xref target="I-D.
etf-lake-edhoc" format="default"/>.</t> ietf-lake-edhoc" format="default"/>.</t>
<t>The 6lo stack uses the IPv6 addressing model. The implications for priv acy and network performance of using L2-address-derived IPv6 addresses need to b e considered <xref target="RFC8065" format="default"/>.</t> <t>The 6lo stack uses the IPv6 addressing model. The implications for priv acy and network performance of using L2-address-derived IPv6 addresses need to b e considered <xref target="RFC8065" format="default"/>.</t>
</section> </section>
<!-- Section 8 - Acknowledgements -->
<section anchor="Acknowledgements" numbered="true" toc="default">
<name>Acknowledgements</name>
<t>Carles Gomez has been funded in part by the Spanish Government through
the Jose Castillejo CAS15/00336 grant, the TEC2016-79988-P grant, and the PID201
9-106808RA-I00 grant, and by Secretaria d'Universitats i Recerca del Departament
d'Empresa i Coneixement de la Generalitat de Catalunya 2017 through grant SGR 3
76. His contribution to this work has been carried out in part during his stay a
s a visiting scholar at the Computer Laboratory of the University of Cambridge.
</t>
<t>Thomas Watteyne, Pascal Thubert, Xavier Vilajosana, Daniel Migault, Jia
nqiang Hou, Kerry Lynn, S.V.R. Anand, and Seyed Mahdi Darroudi have provided val
uable feedback for this draft.</t>
<t>Das Subir and Michel Veillette have provided valuable information of ju
piterMesh and Paul Duffy has provided valuable information of Wi-SUN for this dr
aft. Also, Jianqiang Hou has provided valuable information of G3-PLC and Netrici
ty for this draft. Take Aanstoot, Kerry Lynn, and Dave Robin have provided valua
ble information of MS/TP and practical use case of MS/TP for this draft.</t>
<t> Deoknyong Ko has provided relevant text of LTE-MTC and he shared his e
xperience to deploy IPv6 and 6lo technologies over LTE MTC in SK Telecom.</t>
</section>
</middle>
<!-- *****BACK MATTER ***** -->
<back>
<!-- References split into informative and normative -->
<!-- There are 2 ways to insert reference entries from the citation librarie
s:
1. define an ENTITY at the top, and use "ampersand character"RFC2629; here
(as shown)
2. simply use a PI "less than character"?rfc include="reference.RFC.2119.xm
l"?> here
(for I-Ds: include="reference.I-D.narten-iana-considerations-rfc2434bis.xml
")
Both are cited textually in the same manner: by using xref elements. </middle>
If you use the PI option, xml2rfc will, by default, try to find included fi
les in the same
directory as the including file. You can also define the XML_LIBRARY enviro
nment variable
with a value containing a set of directories to search. These can be eithe
r in the local
filing system or remote ones accessed by http (http://domain/dir/... ).-->
<!--
<references title="Normative References">
&rfc2119; <back>;
</references> <displayreference target="I-D.ietf-iotops-security-protocol-comparison" to="SEC-
PROT-COMP"/>
<displayreference target="I-D.ietf-lake-edhoc" to="EDHOC"/>
<references> <references>
<name>References</name> <name>References</name>
<references> <references>
<name>Normative References</name> <name>Normative References</name>
<reference anchor="RFC4861" target="https://www.rfc-editor.org/info/rfc486
1" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4861.xml">
<front>
<title>Neighbor Discovery for IP version 6 (IPv6)</title>
<author fullname="T. Narten" initials="T." surname="Narten"/>
<author fullname="E. Nordmark" initials="E." surname="Nordmark"/>
<author fullname="W. Simpson" initials="W." surname="Simpson"/>
<author fullname="H. Soliman" initials="H." surname="Soliman"/>
<date month="September" year="2007"/>
<abstract>
<t>This document specifies the Neighbor Discovery protocol for IP Ve
rsion 6. IPv6 nodes on the same link use Neighbor Discovery to discover each ot
her's presence, to determine each other's link-layer addresses, to find routers,
and to maintain reachability information about the paths to active neighbors. [
STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="4861"/>
<seriesInfo name="DOI" value="10.17487/RFC4861"/>
</reference>
<reference anchor="RFC4862" target="https://www.rfc-editor.org/info/rfc486
2" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4862.xml">
<front>
<title>IPv6 Stateless Address Autoconfiguration</title>
<author fullname="S. Thomson" initials="S." surname="Thomson"/>
<author fullname="T. Narten" initials="T." surname="Narten"/>
<author fullname="T. Jinmei" initials="T." surname="Jinmei"/>
<date month="September" year="2007"/>
<abstract>
<t>This document specifies the steps a host takes in deciding how to
autoconfigure its interfaces in IP version 6. The autoconfiguration process in
cludes generating a link-local address, generating global addresses via stateles
s address autoconfiguration, and the Duplicate Address Detection procedure to ve
rify the uniqueness of the addresses on a link. [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="4862"/>
<seriesInfo name="DOI" value="10.17487/RFC4862"/>
</reference>
<reference anchor="RFC4919" target="https://www.rfc-editor.org/info/rfc491
9" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4919.xml">
<front>
<title>IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs):
Overview, Assumptions, Problem Statement, and Goals</title>
<author fullname="N. Kushalnagar" initials="N." surname="Kushalnagar"/
>
<author fullname="G. Montenegro" initials="G." surname="Montenegro"/>
<author fullname="C. Schumacher" initials="C." surname="Schumacher"/>
<date month="August" year="2007"/>
<abstract>
<t>This document describes the assumptions, problem statement, and g
oals for transmitting IP over IEEE 802.15.4 networks. The set of goals enumerat
ed in this document form an initial set only. This memo provides information fo
r the Internet community.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="4919"/>
<seriesInfo name="DOI" value="10.17487/RFC4919"/>
</reference>
<reference anchor="RFC4944" target="https://www.rfc-editor.org/info/rfc494
4" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4944.xml">
<front>
<title>Transmission of IPv6 Packets over IEEE 802.15.4 Networks</title
>
<author fullname="G. Montenegro" initials="G." surname="Montenegro"/>
<author fullname="N. Kushalnagar" initials="N." surname="Kushalnagar"/
>
<author fullname="J. Hui" initials="J." surname="Hui"/>
<author fullname="D. Culler" initials="D." surname="Culler"/>
<date month="September" year="2007"/>
<abstract>
<t>This document describes the frame format for transmission of IPv6
packets and the method of forming IPv6 link-local addresses and statelessly aut
oconfigured addresses on IEEE 802.15.4 networks. Additional specifications incl
ude a simple header compression scheme using shared context and provisions for p
acket delivery in IEEE 802.15.4 meshes. [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="4944"/>
<seriesInfo name="DOI" value="10.17487/RFC4944"/>
</reference>
<reference anchor="RFC6568" target="https://www.rfc-editor.org/
info/rfc6568" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.656
8.xml">
<front>
<title>Design and Application Spaces for IPv6 over Low-Power Wireless
Personal Area Networks (6LoWPANs)</title>
<author fullname="E. Kim" initials="E." surname="Kim"/>
<author fullname="D. Kaspar" initials="D." surname="Kaspar"/>
<author fullname="JP. Vasseur" initials="JP." surname="Vasseur"/>
<date month="April" year="2012"/>
<abstract>
<t>This document investigates potential application scenarios and us
e cases for low-power wireless personal area networks (LoWPANs). This document
provides dimensions of design space for LoWPAN applications. A list of use case
s and market domains that may benefit and motivate the work currently done in th
e 6LoWPAN Working Group is provided with the characteristics of each dimension.
A complete list of practical use cases is not the goal of this document. This
document is not an Internet Standards Track specification; it is published for i
nformational purposes.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="6568"/>
<seriesInfo name="DOI" value="10.17487/RFC6568"/>
</reference>
<reference anchor="RFC6606" target="https://www.rfc-editor.org/info/rfc660
6" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6606.xml">
<front>
<title>Problem Statement and Requirements for IPv6 over Low-Power Wire
less Personal Area Network (6LoWPAN) Routing</title>
<author fullname="E. Kim" initials="E." surname="Kim"/>
<author fullname="D. Kaspar" initials="D." surname="Kaspar"/>
<author fullname="C. Gomez" initials="C." surname="Gomez"/>
<author fullname="C. Bormann" initials="C." surname="Bormann"/>
<date month="May" year="2012"/>
<abstract>
<t>IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs) ar
e formed by devices that are compatible with the IEEE 802.15.4 standard. However
, neither the IEEE 802.15.4 standard nor the 6LoWPAN format specification define
s how mesh topologies could be obtained and maintained. Thus, it should be consi
dered how 6LoWPAN formation and multi-hop routing could be supported.</t>
<t>This document provides the problem statement and design space for
6LoWPAN routing. It defines the routing requirements for 6LoWPANs, considering
the low-power and other particular characteristics of the devices and links. The
purpose of this document is not to recommend specific solutions but to provide
general, layer-agnostic guidelines about the design of 6LoWPAN routing that can
lead to further analysis and protocol design. This document is intended as input
to groups working on routing protocols relevant to 6LoWPANs, such as the IETF R
OLL WG. This document is not an Internet Standards Track specification; it is pu
blished for informational purposes.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="6606"/>
<seriesInfo name="DOI" value="10.17487/RFC6606"/>
</reference>
<reference anchor="RFC7228" target="https://www.rfc-editor.org/info/rfc722
8" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7228.xml">
<front>
<title>Terminology for Constrained-Node Networks</title>
<author fullname="C. Bormann" initials="C." surname="Bormann"/>
<author fullname="M. Ersue" initials="M." surname="Ersue"/>
<author fullname="A. Keranen" initials="A." surname="Keranen"/>
<date month="May" year="2014"/>
<abstract>
<t>The Internet Protocol Suite is increasingly used on small devices
with severe constraints on power, memory, and processing resources, creating co
nstrained-node networks. This document provides a number of basic terms that ha
ve been useful in the standardization work for constrained-node networks.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="7228"/>
<seriesInfo name="DOI" value="10.17487/RFC7228"/>
</reference>
<reference anchor="RFC7400" target="https://www.rfc-editor.org/info/rfc740
0" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7400.xml">
<front>
<title>6LoWPAN-GHC: Generic Header Compression for IPv6 over Low-Power
Wireless Personal Area Networks (6LoWPANs)</title>
<author fullname="C. Bormann" initials="C." surname="Bormann"/>
<date month="November" year="2014"/>
<abstract>
<t>RFC 6282 defines header compression in 6LoWPAN packets (where "6L
oWPAN" refers to "IPv6 over Low-Power Wireless Personal Area Network"). The pre
sent document specifies a simple addition that enables the compression of generi
c headers and header-like payloads, without a need to define a new header compre
ssion scheme for each such new header or header-like payload.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="7400"/>
<seriesInfo name="DOI" value="10.17487/RFC7400"/>
</reference>
<reference anchor="RFC7428" target="https://www.rfc-editor.org/info/rfc742
8" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7428.xml">
<front>
<title>Transmission of IPv6 Packets over ITU-T G.9959 Networks</title>
<author fullname="A. Brandt" initials="A." surname="Brandt"/>
<author fullname="J. Buron" initials="J." surname="Buron"/>
<date month="February" year="2015"/>
<abstract>
<t>This document describes the frame format for transmission of IPv6
packets as well as a method of forming IPv6 link-local addresses and statelessl
y autoconfigured IPv6 addresses on ITU-T G.9959 networks.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="7428"/>
<seriesInfo name="DOI" value="10.17487/RFC7428"/>
</reference>
<reference anchor="RFC7668" target="https://www.rfc-editor.org/info/rfc766
8" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7668.xml">
<front>
<title>IPv6 over BLUETOOTH(R) Low Energy</title>
<author fullname="J. Nieminen" initials="J." surname="Nieminen"/>
<author fullname="T. Savolainen" initials="T." surname="Savolainen"/>
<author fullname="M. Isomaki" initials="M." surname="Isomaki"/>
<author fullname="B. Patil" initials="B." surname="Patil"/>
<author fullname="Z. Shelby" initials="Z." surname="Shelby"/>
<author fullname="C. Gomez" initials="C." surname="Gomez"/>
<date month="October" year="2015"/>
<abstract>
<t>Bluetooth Smart is the brand name for the Bluetooth low energy fe
ature in the Bluetooth specification defined by the Bluetooth Special Interest G
roup. The standard Bluetooth radio has been widely implemented and available in
mobile phones, notebook computers, audio headsets, and many other devices. The
low-power version of Bluetooth is a specification that enables the use of this
air interface with devices such as sensors, smart meters, appliances, etc. The
low-power variant of Bluetooth has been standardized since revision 4.0 of the B
luetooth specifications, although version 4.1 or newer is required for IPv6. Th
is document describes how IPv6 is transported over Bluetooth low energy using IP
v6 over Low-power Wireless Personal Area Network (6LoWPAN) techniques.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="7668"/>
<seriesInfo name="DOI" value="10.17487/RFC7668"/>
</reference>
<reference anchor="RFC8105" target="https://www.rfc-editor.org/info/rfc810
5" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8105.xml">
<front>
<title>Transmission of IPv6 Packets over Digital Enhanced Cordless Tel
ecommunications (DECT) Ultra Low Energy (ULE)</title>
<author fullname="P. Mariager" initials="P." surname="Mariager"/>
<author fullname="J. Petersen" initials="J." role="editor" surname="Pe
tersen"/>
<author fullname="Z. Shelby" initials="Z." surname="Shelby"/>
<author fullname="M. Van de Logt" initials="M." surname="Van de Logt"/
>
<author fullname="D. Barthel" initials="D." surname="Barthel"/>
<date month="May" year="2017"/>
<abstract>
<t>Digital Enhanced Cordless Telecommunications (DECT) Ultra Low Ene
rgy (ULE) is a low-power air interface technology that is proposed by the DECT F
orum and is defined and specified by ETSI.</t>
<t>The DECT air interface technology has been used worldwide in comm
unication devices for more than 20 years. It has primarily been used to carry vo
ice for cordless telephony but has also been deployed for data-centric services.
</t>
<t>DECT ULE is a recent addition to the DECT interface primarily int
ended for low-bandwidth, low-power applications such as sensor devices, smart me
ters, home automation, etc. As the DECT ULE interface inherits many of the capab
ilities from DECT, it benefits from operation that is long-range and interferenc
e-free, worldwide- reserved frequency band, low silicon prices, and maturity. Th
ere is an added value in the ability to communicate with IPv6 over DECT ULE, suc
h as for Internet of Things applications.</t>
<t>This document describes how IPv6 is transported over DECT ULE usi
ng IPv6 over Low-Power Wireless Personal Area Network (6LoWPAN) techniques.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="8105"/>
<seriesInfo name="DOI" value="10.17487/RFC8105"/>
</reference>
<reference anchor="RFC8163" target="https://www.rfc-editor.org/info/rfc816
3" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8163.xml">
<front>
<title>Transmission of IPv6 over Master-Slave/Token-Passing (MS/TP) Ne
tworks</title>
<author fullname="K. Lynn" initials="K." role="editor" surname="Lynn"/
>
<author fullname="J. Martocci" initials="J." surname="Martocci"/>
<author fullname="C. Neilson" initials="C." surname="Neilson"/>
<author fullname="S. Donaldson" initials="S." surname="Donaldson"/>
<date month="May" year="2017"/>
<abstract>
<t>Master-Slave/Token-Passing (MS/TP) is a medium access control met
hod for the RS-485 physical layer and is used primarily in building automation n
etworks. This specification defines the frame format for transmission of IPv6 p
ackets and the method of forming link-local and statelessly autoconfigured IPv6
addresses on MS/TP networks.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="8163"/>
<seriesInfo name="DOI" value="10.17487/RFC8163"/>
</reference>
<reference anchor="RFC8200" target="https://www.rfc-editor.org/info/rfc820 <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4861.xml"
0" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8200.xml"> />
<front> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4862.xml"
<title>Internet Protocol, Version 6 (IPv6) Specification</title> />
<author fullname="S. Deering" initials="S." surname="Deering"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4919.xml"
<author fullname="R. Hinden" initials="R." surname="Hinden"/> />
<date month="July" year="2017"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4944.xml"
<abstract> />
<t>This document specifies version 6 of the Internet Protocol (IPv6) <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6568.xml"
. It obsoletes RFC 2460.</t> />
</abstract> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6606.xml"
</front> />
<seriesInfo name="STD" value="86"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7228.xml"
<seriesInfo name="RFC" value="8200"/> />
<seriesInfo name="DOI" value="10.17487/RFC8200"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7400.xml"
</reference> />
<reference anchor="RFC9159" target="https://www.rfc-editor.org/info/rfc915 <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7428.xml"
9" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9159.xml"> />
<front> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7668.xml"
<title>IPv6 Mesh over BLUETOOTH(R) Low Energy Using the Internet Proto />
col Support Profile (IPSP)</title> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8105.xml"
<author fullname="C. Gomez" initials="C." surname="Gomez"/> />
<author fullname="S.M. Darroudi" initials="S.M." surname="Darroudi"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8163.xml"
<author fullname="T. Savolainen" initials="T." surname="Savolainen"/> />
<author fullname="M. Spoerk" initials="M." surname="Spoerk"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8200.xml"
<date month="December" year="2021"/> />
<abstract> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9159.xml"
<t>RFC 7668 describes the adaptation of IPv6 over Low-Power Wireless />
Personal Area Network (6LoWPAN) techniques to enable IPv6 over Bluetooth Low En
ergy (Bluetooth LE) networks that follow the star topology. However, recent Blu <!-- [RFC9354] Updated to long version because incorrectly showing Hong's initia
etooth specifications allow the formation of extended topologies as well. This ls as just "Y." instead of "Y-G."
document specifies mechanisms that are needed to enable IPv6 mesh over Bluetooth -->
LE links established by using the Bluetooth Internet Protocol Support Profile (
IPSP). This document does not specify the routing protocol to be used in an IPv
6 mesh over Bluetooth LE links.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="9159"/>
<seriesInfo name="DOI" value="10.17487/RFC9159"/>
</reference>
<reference anchor="RFC9354" target="https://www.rfc-editor.org/info/rfc935
4" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9354.xml">
<front>
<title>Transmission of IPv6 Packets over Power Line Communication (PLC
) Networks</title>
<author fullname="J. Hou" initials="J." surname="Hou"/>
<author fullname="B. Liu" initials="B." surname="Liu"/>
<author fullname="Y-G. Hong" surname="Y-G. Hong"/>
<author fullname="X. Tang" initials="X." surname="Tang"/>
<author fullname="C. Perkins" initials="C." surname="Perkins"/>
<date month="January" year="2023"/>
<abstract>
<t>Power Line Communication (PLC), namely using electric power lines
for indoor and outdoor communications, has been widely applied to support Advan
ced Metering Infrastructure (AMI), especially smart meters for electricity. The
existing electricity infrastructure facilitates the expansion of PLC deployment
s due to its potential advantages in terms of cost and convenience. Moreover, a
wide variety of accessible devices raises the potential demand of IPv6 for futu
re applications. This document describes how IPv6 packets are transported over
constrained PLC networks, such as those described in ITU-T G.9903, IEEE 1901.1,
and IEEE 1901.2.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="9354"/>
<seriesInfo name="DOI" value="10.17487/RFC9354"/>
</reference>
</references>
<reference anchor="RFC9354" target="https://www.rfc-editor.org/info/rfc9354">
<front>
<title>Transmission of IPv6 Packets over Power Line Communication (PLC) Networks
</title>
<author fullname="J. Hou" initials="J." surname="Hou"/>
<author fullname="B. Liu" initials="B." surname="Liu"/>
<author fullname="Y-G. Hong" initials="Y-G." surname="Hong"/>
<author fullname="X. Tang" initials="X." surname="Tang"/>
<author fullname="C. Perkins" initials="C." surname="Perkins"/>
<date month="January" year="2023"/>
</front>
<seriesInfo name="RFC" value="9354"/>
<seriesInfo name="DOI" value="10.17487/RFC9354"/>
</reference>
</references>
<references> <references>
<name>Informative References</name> <name>Informative References</name>
<reference anchor="BACnet" target="https://www.techstreet.com/ashrae/stand ards/ashrae-135-2016?product_id=1918140#jumps"> <reference anchor="BACnet" target="https://www.techstreet.com/standards/as hrae-135-2020?product_id=2191852">
<front> <front>
<title>ASHRAE, "BACnet-A Data Communication Protocol for Building <title>BACnet-A Data Communication Protocol for Building
Automation and Control Networks", ANSI/ASHRAE Standard Automation and Control Networks (ANSI Approved)</title>
135-2016</title> <author>
<author/> <organization>ASHRAE</organization>
<date month="January" year="2016"/> </author>
<date month="October" year="2020"/>
</front> </front>
<seriesInfo name="ASHRAE Standard" value="135-2020"/>
</reference> </reference>
<reference anchor="G.9903">
<reference anchor="G.9903" target="https://www.itu.int/rec/T-REC-G.9903-20
1708-I/en">
<front> <front>
<title>International Telecommunication Union, "Narrowband orthogonal f <title>Narrowband orthogonal frequency division multiplexing power
requency division multiplexing power line communication transceivers for G3-PLC line communication transceivers for G3-PLC networks</title>
networks", ITU-T Recommendation</title> <author>
<author/> <organization>ITU-T</organization>
</author>
<date month="August" year="2017"/> <date month="August" year="2017"/>
</front> </front>
<seriesInfo name="ITU-T Recommendation" value="G.9903"/>
</reference> </reference>
<reference anchor="G.9959">
<reference anchor="G.9959" target="https://www.itu.int/rec/T-REC-G.9959-20
1501-I/en">
<front> <front>
<title>International Telecommunication Union, "Short range <title>Short range narrow-band digital radiocommunication
narrow-band digital radiocommunication transceivers - PHY and MAC layer specific transceivers - PHY, MAC, SAR and LLC layer specifications</title>
ations", ITU-T Recommendation</title> <author>
<author/> <organization>ITU-T</organization>
</author>
<date month="January" year="2015"/> <date month="January" year="2015"/>
</front> </front>
<seriesInfo name="ITU-T Recommendation" value="G.9959"/>
</reference> </reference>
<reference anchor="G3-PLC" target="https://g3-plc.com"> <reference anchor="G3-PLC" target="https://g3-plc.com">
<front> <front>
<title>G3-PLC Alliance</title> <title>G3-Alliance</title>
<author/> <author/>
<date month="" year=""/>
</front> </front>
</reference> </reference>
<reference anchor="IEEE1901" target="https://standards.ieee.org/findstds/s
tandard/1901-2010.html"> <reference anchor="IEEE-1901" target="https://standards.ieee.org/ieee/1901
/4953/">
<front> <front>
<title>IEEE Standard, IEEE Std 1901-2010 - IEEE Standard for Broadband <title>IEEE Standard for Broadband over Power Line Networks: Medium
over Power Line Networks: Medium Access Control and Physical Layer Specificatio Access Control and Physical Layer Specifications </title>
ns </title> <author>
<author/> <organization>IEEE</organization>
<date month="" year="2010"/> </author>
<date month="December" year="2010"/>
</front> </front>
<seriesInfo name="DOI" value="10.1109/IEEESTD.2010.5678772"/>
<seriesInfo name="IEEE Std" value="1901-2010"/>
</reference> </reference>
<reference anchor="IEEE1901.1" target="https://ieeexplore.ieee.org/documen
t/8360785"> <reference anchor="IEEE-1901.1" target="https://ieeexplore.ieee.org/docume
nt/8360785">
<front> <front>
<title>IEEE Standard, IEEE Std 1901.1-2018 - IEEE Standard for Medium <title>IEEE Standard for Medium Frequency (less than 12 MHz) Power
Frequency (less than 12 MHz) Power Line Communications for Smart Grid Applicatio Line Communications for Smart Grid Applications</title>
ns</title> <author>
<author/> <organization>IEEE</organization>
<date month="" year="2018"/> </author>
<date month="May" year="2018"/>
</front> </front>
<seriesInfo name="DOI" value="10.1109/IEEESTD.2018.8360785"/>
<seriesInfo name="IEEE Std" value="1901.1-2018"/>
</reference> </reference>
<reference anchor="IEEE1901.2" target="https://standards.ieee.org/ieee/190
1.2/4833/"> <reference anchor="IEEE-1901.2" target="https://standards.ieee.org/ieee/19
01.2/4833/">
<front> <front>
<title>IEEE Standard, IEEE Std 1901.2-2013 - IEEE Standard for Low-Fre <title>IEEE Standard for Low-Frequency (less than 500 kHz)
quency (less than 500 kHz) Narrowband Power Line Communications for Smart Grid A Narrowband Power Line Communications for Smart Grid
pplications</title> Applications</title>
<author/> <author>
<date month="" year="2013"/> <organization>IEEE</organization>
</author>
<date month="December" year="2013"/>
</front> </front>
<seriesInfo name="DOI" value="10.1109/IEEESTD.2013.6679210"/>
<seriesInfo name="IEEE Std" value="1901.2-2013"/>
</reference> </reference>
<reference anchor="IEEE802154" target="https://standards.ieee.org/ieee/
802.15.4/7029/"> <reference anchor="IEEE-802.15.4" target="https://standards.ieee.org/ie
ee/802.15.4/7029/">
<front> <front>
<title>IEEE Standard for Low-Rate Wireless Networks, IEEE Std. <title>IEEE Standard for Low-Rate Wireless Networks</title>
802.15.4-2020</title> <author>
<author fullname="" initials="" surname="IEEE Computer Society" <organization>IEEE</organization>
/> </author>
<date month="" year="2020"/> <date month="July" year="2020"/>
</front> </front>
<seriesInfo name="IEEE" value=""/> <seriesInfo name="DOI" value="10.1109/IEEESTD.2020.9144691"/>
<seriesInfo name="IEEE Std" value="802.15.4-2020"/>
</reference> </reference>
<reference anchor="IEEE802159" target="https://standards.ieee.org/ieee/802
.15.9/7967/"> <reference anchor="IEEE-802.15.9" target="https://ieeexplore.ieee.org/docu
ment/9690134">
<front> <front>
<title>IEEE Standard for Transport of Key Management Protocol (KMP) Da tagrams <title>IEEE Standard for Transport of Key Management Protocol (KMP) Da tagrams
</title> </title>
<author fullname="" initials="" surname="IEEE Computer Society"/> <author>
<date month="" year="2021"/> <organization>IEEE</organization>
</front> </author>
</reference> <date month="January" year="2022"/>
<reference anchor="I-D.ietf-6lo-nfc" target="https://www.ietf.org/archive/
id/draft-ietf-6lo-nfc-22.txt" xml:base="https://bib.ietf.org/public/rfc/bibxml3/
reference.I-D.draft-ietf-6lo-nfc-22.xml">
<front>
<title>Transmission of IPv6 Packets over Near Field Communication</tit
le>
<author fullname="Younghwan Choi" initials="Y." surname="Choi">
<organization>Electronics and Telecommunications Research Institute<
/organization>
</author>
<author fullname="Yong-Geun Hong" initials="Y." surname="Hong">
<organization>Daejon University</organization>
</author>
<author fullname="Joo-Sang Youn" initials="J." surname="Youn">
<organization>DONG-EUI University</organization>
</author>
<date day="9" month="March" year="2023"/>
<abstract>
<t>Near Field Communication (NFC) is a set of standards for smartpho
nes and portable devices to establish radio communication with each other by tou
ching them together or bringing them into proximity, usually no more than 10 cm
apart. NFC standards cover communications protocols and data exchange formats, a
nd are based on existing radio-frequency identification (RFID) standards includi
ng ISO/IEC 14443 and FeliCa. The standards include ISO/IEC 18092 and those defin
ed by the NFC Forum. The NFC technology has been widely implemented and availabl
e in mobile phones, laptop computers, and many other devices. This document desc
ribes how IPv6 is transmitted over NFC using 6LoWPAN techniques.</t>
</abstract>
</front> </front>
<seriesInfo name="Internet-Draft" value="draft-ietf-6lo-nfc-22"/> <seriesInfo name="DOI" value="10.1109/IEEESTD.2022.9690134"/>
<seriesInfo name="IEEE Std" value="802.15.9-2021"/>
</reference> </reference>
<reference anchor="I-D.ietf-lwig-security-protocol-comparison" target="https://d
atatracker.ietf.org/doc/html/draft-ietf-lwig-security-protocol-comparison-07"> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9428.xml"
<front> />
<title>Comparison of CoAP Security Protocols</title>
<author fullname="John Mattsson" initials="J. P." surname="Mattsson"> <!-- [I-D.ietf-lwig-security-protocol-comparison] Replaced by [I-D.ietf-iotops-s
<organization>Ericsson AB</organization> ecurity-protocol-comparison] IESG state I-D Exists.
</author>
<author fullname="Francesca Palombini" initials="F." surname="Palombini"> Updated to long version because Mattsson's last name is showing incorrectly.
<organization>Ericsson AB</organization> -->
</author>
<author fullname="Mali?a Vu?ini?" initials="M." surname="Vu?ini?"> <reference anchor="I-D.ietf-iotops-security-protocol-comparison" target="https:/
<organization>INRIA</organization> /datatracker.ietf.org/doc/html/draft-ietf-iotops-security-protocol-comparison-02
</author> ">
<date day="24" month="January" year="2023"/> <front>
<abstract> <title>Comparison of CoAP Security Protocols</title>
<t>This document analyzes and compares the sizes of key exchange flights a <author initials="J." surname="Preuß Mattsson" fullname="John Preuß Mattsson">
nd the per-packet message size overheads when using different security protocols <organization>Ericsson AB</organization>
to secure CoAP. Small message sizes are very important for reducing energy cons </author>
umption, latency, and time to completion in constrained radio network such as Lo <author initials="F." surname="Palombini" fullname="Francesca Palombini">
w-Power Wide Area Networks (LPWANs). The analyzed security protocols are DTLS 1. <organization>Ericsson AB</organization>
2, DTLS 1.3, TLS 1.2, TLS 1.3, cTLS, EDHOC, OSCORE, and Group OSCORE. The DTLS a </author>
nd TLS record layers are analyzed with and without 6LoWPAN- GHC compression. DTL <author initials="M." surname="Vučinić" fullname="Mališa Vučinić">
S is analyzed with and without Connection ID.</t> <organization>INRIA</organization>
</abstract> </author>
</front> <date month="April" day="11" year="2023"/>
<seriesInfo name="Internet-Draft" value="draft-ietf-lwig-security-protocol-com </front>
parison-07"/> <seriesInfo name="Internet-Draft" value="draft-ietf-iotops-security-protocol-com
parison-02"/>
</reference> </reference>
<reference anchor="Wi-SUN" target="https://www.wi-sun.org"> <reference anchor="Wi-SUN" target="https://www.wi-sun.org">
<front> <front>
<title>Wi-SUN Alliance</title> <title>Wi-SUN Alliance</title>
<author/> <author/>
<date month="" year=""/>
</front> </front>
</reference> </reference>
<reference anchor="Thread" target="https://www.threadgroup.org/Support"> <reference anchor="Thread" target="https://www.threadgroup.org/Support">
<front> <front>
<title>Thread Group</title> <title>Resources</title>
<author/> <author>
<date month="" year=""/> <organization>Thread</organization>
</author>
</front> </front>
</reference> </reference>
<reference anchor="NETRICITY" target="https://www.netricity.org/"> <reference anchor="NETRICITY" target="https://www.netricity.org/">
<front> <front>
<title>Netricity program in HomePlug Powerline Alliance</title> <title>The Netricity program addresses the need for long range
<author/> powerline networking for outside-the-home, smart meter-to-grid, and
<date month="" year=""/> industrial control applications</title>
</front> <author>
</reference> <organization>Netricity</organization>
<reference anchor="RFC3756" target="https://www.rfc-editor.org/info/rfc375 </author>
6" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3756.xml">
<front>
<title>IPv6 Neighbor Discovery (ND) Trust Models and Threats</title>
<author fullname="P. Nikander" initials="P." role="editor" surname="Ni
kander"/>
<author fullname="J. Kempf" initials="J." surname="Kempf"/>
<author fullname="E. Nordmark" initials="E." surname="Nordmark"/>
<date month="May" year="2004"/>
<abstract>
<t>The existing IETF standards specify that IPv6 Neighbor Discovery
(ND) and Address Autoconfiguration mechanisms may be protected with IPsec Authen
tication Header (AH). However, the current specifications limit the security so
lutions to manual keying due to practical problems faced with automatic key mana
gement. This document specifies three different trust models and discusses the
threats pertinent to IPv6 Neighbor Discovery. The purpose of this discussion is
to define the requirements for Securing IPv6 Neighbor Discovery. This memo pro
vides information for the Internet community.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="3756"/>
<seriesInfo name="DOI" value="10.17487/RFC3756"/>
</reference>
<reference anchor="RFC6282" target="https://www.rfc-editor.org/info/rfc628
2" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6282.xml">
<front>
<title>Compression Format for IPv6 Datagrams over IEEE 802.15.4-Based
Networks</title>
<author fullname="J. Hui" initials="J." role="editor" surname="Hui"/>
<author fullname="P. Thubert" initials="P." surname="Thubert"/>
<date month="September" year="2011"/>
<abstract>
<t>This document updates RFC 4944, "Transmission of IPv6 Packets ove
r IEEE 802.15.4 Networks". This document specifies an IPv6 header compression f
ormat for IPv6 packet delivery in Low Power Wireless Personal Area Networks (6Lo
WPANs). The compression format relies on shared context to allow compression of
arbitrary prefixes. How the information is maintained in that shared context i
s out of scope. This document specifies compression of multicast addresses and
a framework for compressing next headers. UDP header compression is specified w
ithin this framework. [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="6282"/>
<seriesInfo name="DOI" value="10.17487/RFC6282"/>
</reference>
<reference anchor="RFC6550" target="https://www.rfc-editor.org/info/rfc655
0" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6550.xml">
<front>
<title>RPL: IPv6 Routing Protocol for Low-Power and Lossy Networks</ti
tle>
<author fullname="T. Winter" initials="T." role="editor" surname="Wint
er"/>
<author fullname="P. Thubert" initials="P." role="editor" surname="Thu
bert"/>
<author fullname="A. Brandt" initials="A." surname="Brandt"/>
<author fullname="J. Hui" initials="J." surname="Hui"/>
<author fullname="R. Kelsey" initials="R." surname="Kelsey"/>
<author fullname="P. Levis" initials="P." surname="Levis"/>
<author fullname="K. Pister" initials="K." surname="Pister"/>
<author fullname="R. Struik" initials="R." surname="Struik"/>
<author fullname="JP. Vasseur" initials="JP." surname="Vasseur"/>
<author fullname="R. Alexander" initials="R." surname="Alexander"/>
<date month="March" year="2012"/>
<abstract>
<t>Low-Power and Lossy Networks (LLNs) are a class of network in whi
ch both the routers and their interconnect are constrained. LLN routers typical
ly operate with constraints on processing power, memory, and energy (battery pow
er). Their interconnects are characterized by high loss rates, low data rates,
and instability. LLNs are comprised of anything from a few dozen to thousands o
f routers. Supported traffic flows include point-to-point (between devices insi
de the LLN), point-to-multipoint (from a central control point to a subset of de
vices inside the LLN), and multipoint-to-point (from devices inside the LLN towa
rds a central control point). This document specifies the IPv6 Routing Protocol
for Low-Power and Lossy Networks (RPL), which provides a mechanism whereby mult
ipoint-to-point traffic from devices inside the LLN towards a central control po
int as well as point-to-multipoint traffic from the central control point to the
devices inside the LLN are supported. Support for point-to-point traffic is al
so available. [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="6550"/>
<seriesInfo name="DOI" value="10.17487/RFC6550"/>
</reference>
<reference anchor="RFC6620" target="https://www.rfc-editor.org/info/rfc66
20" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6620.xml">
<front>
<title>FCFS SAVI: First-Come, First-Served Source Address Validation I
mprovement for Locally Assigned IPv6 Addresses</title>
<author fullname="E. Nordmark" initials="E." surname="Nordmark"/>
<author fullname="M. Bagnulo" initials="M." surname="Bagnulo"/>
<author fullname="E. Levy-Abegnoli" initials="E." surname="Levy-Abegno
li"/>
<date month="May" year="2012"/>
<abstract>
<t>This memo describes First-Come, First-Served Source Address Valid
ation Improvement (FCFS SAVI), a mechanism that provides source address validati
on for IPv6 networks using the FCFS principle. The proposed mechanism is intend
ed to complement ingress filtering techniques to help detect and prevent source
address spoofing. [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="6620"/>
<seriesInfo name="DOI" value="10.17487/RFC6620"/>
</reference>
<reference anchor="RFC6775" target="https://www.rfc-editor.org/info/rfc677
5" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6775.xml">
<front>
<title>Neighbor Discovery Optimization for IPv6 over Low-Power Wireles
s Personal Area Networks (6LoWPANs)</title>
<author fullname="Z. Shelby" initials="Z." role="editor" surname="Shel
by"/>
<author fullname="S. Chakrabarti" initials="S." surname="Chakrabarti"/
>
<author fullname="E. Nordmark" initials="E." surname="Nordmark"/>
<author fullname="C. Bormann" initials="C." surname="Bormann"/>
<date month="November" year="2012"/>
<abstract>
<t>The IETF work in IPv6 over Low-power Wireless Personal Area Netwo
rk (6LoWPAN) defines 6LoWPANs such as IEEE 802.15.4. This and other similar lin
k technologies have limited or no usage of multicast signaling due to energy con
servation. In addition, the wireless network may not strictly follow the tradit
ional concept of IP subnets and IP links. IPv6 Neighbor Discovery was not desig
ned for non- transitive wireless links, as its reliance on the traditional IPv6
link concept and its heavy use of multicast make it inefficient and sometimes im
practical in a low-power and lossy network. This document describes simple opti
mizations to IPv6 Neighbor Discovery, its addressing mechanisms, and duplicate a
ddress detection for Low- power Wireless Personal Area Networks and similar netw
orks. The document thus updates RFC 4944 to specify the use of the optimization
s defined here. [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="6775"/>
<seriesInfo name="DOI" value="10.17487/RFC6775"/>
</reference>
<reference anchor="RFC8065" target="https://www.rfc-editor.org/info/rfc806
5" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8065.xml">
<front>
<title>Privacy Considerations for IPv6 Adaptation-Layer Mechanisms</ti
tle>
<author fullname="D. Thaler" initials="D." surname="Thaler"/>
<date month="February" year="2017"/>
<abstract>
<t>This document discusses how a number of privacy threats apply to
technologies designed for IPv6 over various link-layer protocols, and it provide
s advice to protocol designers on how to address such threats in adaptation-laye
r specifications for IPv6 over such links.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="8065"/>
<seriesInfo name="DOI" value="10.17487/RFC8065"/>
</reference>
<reference anchor="RFC8066" target="https://www.rfc-editor.org/info/rfc806
6" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8066.xml">
<front>
<title>IPv6 over Low-Power Wireless Personal Area Network (6LoWPAN) ES
C Dispatch Code Points and Guidelines</title>
<author fullname="S. Chakrabarti" initials="S." surname="Chakrabarti"/
>
<author fullname="G. Montenegro" initials="G." surname="Montenegro"/>
<author fullname="R. Droms" initials="R." surname="Droms"/>
<author fullname="J. Woodyatt" initials="J." surname="Woodyatt"/>
<date month="February" year="2017"/>
<abstract>
<t>RFC 4944 defines the ESC dispatch type to allow additional dispat
ch octets in the 6LoWPAN header. The value of the ESC dispatch type was updated
by RFC 6282; however, its usage was not defined in either RFC 6282 or RFC 4944.
This document updates RFC 4944 and RFC 6282 by defining the ESC extension octe
t code points and listing registration entries for known use cases at the time o
f writing of this document.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="8066"/>
<seriesInfo name="DOI" value="10.17487/RFC8066"/>
</reference>
<reference anchor="RFC8138" target="https://www.rfc-editor.org/info/rfc813
8" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8138.xml">
<front>
<title>IPv6 over Low-Power Wireless Personal Area Network (6LoWPAN) Ro
uting Header</title>
<author fullname="P. Thubert" initials="P." role="editor" surname="Thu
bert"/>
<author fullname="C. Bormann" initials="C." surname="Bormann"/>
<author fullname="L. Toutain" initials="L." surname="Toutain"/>
<author fullname="R. Cragie" initials="R." surname="Cragie"/>
<date month="April" year="2017"/>
<abstract>
<t>This specification introduces a new IPv6 over Low-Power Wireless
Personal Area Network (6LoWPAN) dispatch type for use in 6LoWPAN route-over topo
logies, which initially covers the needs of Routing Protocol for Low-Power and L
ossy Networks (RPL) data packet compression (RFC 6550). Using this dispatch typ
e, this specification defines a method to compress the RPL Option (RFC 6553) inf
ormation and Routing Header type 3 (RFC 6554), an efficient IP-in-IP technique,
and is extensible for more applications.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="8138"/>
<seriesInfo name="DOI" value="10.17487/RFC8138"/>
</reference>
<reference anchor="RFC8352" target="https://www.rfc-editor.org/info/rfc835
2" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8352.xml">
<front>
<title>Energy-Efficient Features of Internet of Things Protocols</titl
e>
<author fullname="C. Gomez" initials="C." surname="Gomez"/>
<author fullname="M. Kovatsch" initials="M." surname="Kovatsch"/>
<author fullname="H. Tian" initials="H." surname="Tian"/>
<author fullname="Z. Cao" initials="Z." role="editor" surname="Cao"/>
<date month="April" year="2018"/>
<abstract>
<t>This document describes the challenges for energy-efficient proto
col operation on constrained devices and the current practices used to overcome
those challenges. It summarizes the main link-layer techniques used for energy-
efficient networking, and it highlights the impact of such techniques on the upp
er-layer protocols so that they can together achieve an energy-efficient behavio
r. The document also provides an overview of energy-efficient mechanisms availa
ble at each layer of the IETF protocol suite specified for constrained-node netw
orks.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="8352"/>
<seriesInfo name="DOI" value="10.17487/RFC8352"/>
</reference>
<reference anchor="RFC8376" target="https://www.rfc-editor.org/info/rfc837
6" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8376.xml">
<front>
<title>Low-Power Wide Area Network (LPWAN) Overview</title>
<author fullname="S. Farrell" initials="S." role="editor" surname="Far
rell"/>
<date month="May" year="2018"/>
<abstract>
<t>Low-Power Wide Area Networks (LPWANs) are wireless technologies w
ith characteristics such as large coverage areas, low bandwidth, possibly very s
mall packet and application-layer data sizes, and long battery life operation.
This memo is an informational overview of the set of LPWAN technologies being co
nsidered in the IETF and of the gaps that exist between the needs of those techn
ologies and the goal of running IP in LPWANs.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="8376"/>
<seriesInfo name="DOI" value="10.17487/RFC8376"/>
</reference>
<reference anchor="RFC8505" target="https://www.rfc-editor.org/info/rfc850
5" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8505.xml">
<front>
<title>Registration Extensions for IPv6 over Low-Power Wireless Person
al Area Network (6LoWPAN) Neighbor Discovery</title>
<author fullname="P. Thubert" initials="P." role="editor" surname="Thu
bert"/>
<author fullname="E. Nordmark" initials="E." surname="Nordmark"/>
<author fullname="S. Chakrabarti" initials="S." surname="Chakrabarti"/
>
<author fullname="C. Perkins" initials="C." surname="Perkins"/>
<date month="November" year="2018"/>
<abstract>
<t>This specification updates RFC 6775 -- the Low-Power Wireless Per
sonal Area Network (6LoWPAN) Neighbor Discovery specification -- to clarify the
role of the protocol as a registration technique and simplify the registration o
peration in 6LoWPAN routers, as well as to provide enhancements to the registrat
ion capabilities and mobility detection for different network topologies, includ
ing the Routing Registrars performing routing for host routes and/or proxy Neigh
bor Discovery in a low-power network.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="8505"/>
<seriesInfo name="DOI" value="10.17487/RFC8505"/>
</reference>
<reference anchor="RFC8613" target="https://www.rfc-editor.org/info/rfc861
3" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8613.xml">
<front>
<title>Object Security for Constrained RESTful Environments (OSCORE)</
title>
<author fullname="G. Selander" initials="G." surname="Selander"/>
<author fullname="J. Mattsson" initials="J." surname="Mattsson"/>
<author fullname="F. Palombini" initials="F." surname="Palombini"/>
<author fullname="L. Seitz" initials="L." surname="Seitz"/>
<date month="July" year="2019"/>
<abstract>
<t>This document defines Object Security for Constrained RESTful Env
ironments (OSCORE), a method for application-layer protection of the Constrained
Application Protocol (CoAP), using CBOR Object Signing and Encryption (COSE). O
SCORE provides end-to-end protection between endpoints communicating using CoAP
or CoAP-mappable HTTP. OSCORE is designed for constrained nodes and networks sup
porting a range of proxy operations, including translation between different tra
nsport protocols.</t>
<t>Although an optional functionality of CoAP, OSCORE alters CoAP op
tions processing and IANA registration. Therefore, this document updates RFC 725
2.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="8613"/>
<seriesInfo name="DOI" value="10.17487/RFC8613"/>
</reference>
<reference anchor="RFC8928" target="https://www.rfc-editor.org/info/rfc892
8" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8928.xml">
<front>
<title>Address-Protected Neighbor Discovery for Low-Power and Lossy Ne
tworks</title>
<author fullname="P. Thubert" initials="P." role="editor" surname="Thu
bert"/>
<author fullname="B. Sarikaya" initials="B." surname="Sarikaya"/>
<author fullname="M. Sethi" initials="M." surname="Sethi"/>
<author fullname="R. Struik" initials="R." surname="Struik"/>
<date month="November" year="2020"/>
<abstract>
<t>This document updates the IPv6 over Low-Power Wireless Personal A
rea Network (6LoWPAN) Neighbor Discovery (ND) protocol defined in RFCs 6775 and
8505. The new extension is called Address-Protected Neighbor Discovery (AP-ND),
and it protects the owner of an address against address theft and impersonation
attacks in a Low-Power and Lossy Network (LLN). Nodes supporting this extensio
n compute a cryptographic identifier (Crypto-ID), and use it with one or more of
their Registered Addresses. The Crypto-ID identifies the owner of the Register
ed Address and can be used to provide proof of ownership of the Registered Addre
sses. Once an address is registered with the Crypto-ID and a proof of ownership
is provided, only the owner of that address can modify the registration informa
tion, thereby enforcing Source Address Validation.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="8928"/>
<seriesInfo name="DOI" value="10.17487/RFC8928"/>
</reference>
<reference anchor="RFC8929" target="https://www.rfc-editor.org/info/rfc892
9" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8929.xml">
<front>
<title>IPv6 Backbone Router</title>
<author fullname="P. Thubert" initials="P." role="editor" surname="Thu
bert"/>
<author fullname="C.E. Perkins" initials="C.E." surname="Perkins"/>
<author fullname="E. Levy-Abegnoli" initials="E." surname="Levy-Abegno
li"/>
<date month="November" year="2020"/>
<abstract>
<t>This document updates RFCs 6775 and 8505 in order to enable proxy
services for IPv6 Neighbor Discovery by Routing Registrars called "Backbone Rou
ters". Backbone Routers are placed along the wireless edge of a backbone and fe
derate multiple wireless links to form a single Multi-Link Subnet (MLSN).</t>
</abstract>
</front>
<seriesInfo name="RFC" value="8929"/>
<seriesInfo name="DOI" value="10.17487/RFC8929"/>
</reference>
<reference anchor="RFC9008" target="https://www.rfc-editor.org/info/rfc900
8" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9008.xml">
<front>
<title>Using RPI Option Type, Routing Header for Source Routes, and IP
v6-in-IPv6 Encapsulation in the RPL Data Plane</title>
<author fullname="M.I. Robles" initials="M.I." surname="Robles"/>
<author fullname="M. Richardson" initials="M." surname="Richardson"/>
<author fullname="P. Thubert" initials="P." surname="Thubert"/>
<date month="April" year="2021"/>
<abstract>
<t>This document looks at different data flows through Low-Power and
Lossy Networks (LLN) where RPL (IPv6 Routing Protocol for Low-Power and Lossy N
etworks) is used to establish routing. The document enumerates the cases where
RPL Packet Information (RPI) Option Type (RFC 6553), RPL Source Route Header (RF
C 6554), and IPv6-in-IPv6 encapsulation are required in the data plane. This an
alysis provides the basis upon which to design efficient compression of these he
aders. This document updates RFC 6553 by adding a change to the RPI Option Type
. Additionally, this document updates RFC 6550 by defining a flag in the DODAG
Information Object (DIO) Configuration option to indicate this change and update
s RFC 8138 as well to consider the new Option Type when the RPL Option is decomp
ressed.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="9008"/>
<seriesInfo name="DOI" value="10.17487/RFC9008"/>
</reference>
<reference anchor="RFC9010" target="https://www.rfc-editor.org/info/rfc901
0" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9010.xml">
<front>
<title>Routing for RPL (Routing Protocol for Low-Power and Lossy Netwo
rks) Leaves</title>
<author fullname="P. Thubert" initials="P." role="editor" surname="Thu
bert"/>
<author fullname="M. Richardson" initials="M." surname="Richardson"/>
<date month="April" year="2021"/>
<abstract>
<t>This specification provides a mechanism for a host that implement
s a routing-agnostic interface based on IPv6 over Low-Power Wireless Personal Ar
ea Network (6LoWPAN) Neighbor Discovery to obtain reachability services across a
network that leverages RFC 6550 for its routing operations. It updates RFCs 65
50, 6775, and 8505.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="9010"/>
<seriesInfo name="DOI" value="10.17487/RFC9010"/>
</reference>
<reference anchor="RFC9035" target="https://www.rfc-editor.org/info/rfc903
5" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9035.xml">
<front>
<title>A Routing Protocol for Low-Power and Lossy Networks (RPL) Desti
nation-Oriented Directed Acyclic Graph (DODAG) Configuration Option for the 6LoW
PAN Routing Header</title>
<author fullname="P. Thubert" initials="P." role="editor" surname="Thu
bert"/>
<author fullname="L. Zhao" initials="L." surname="Zhao"/>
<date month="April" year="2021"/>
<abstract>
<t>This document updates RFC 8138 by defining a bit in the Routing P
rotocol for Low-Power and Lossy Networks (RPL) Destination-Oriented Directed Acy
clic Graph (DODAG) Configuration option to indicate whether compression is used
within the RPL Instance and to specify the behavior of nodes compliant with RFC
8138 when the bit is set and unset.</t>
</abstract>
</front> </front>
<seriesInfo name="RFC" value="9035"/>
<seriesInfo name="DOI" value="10.17487/RFC9035"/>
</reference> </reference>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3756.xml"
/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6282.xml"
/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6550.xml"
/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6620.xml"
/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6775.xml"
/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8065.xml"
/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8066.xml"
/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8138.xml"
/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8352.xml"
/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8376.xml"
/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8505.xml"
/>
<!-- Reference RFC 8613 updated to long version because Mattsson's name is showi
ng without first part of last name.-->
<reference anchor="RFC8613" target="https://www.rfc-editor.org/info/rfc8613">
<front>
<title>
Object Security for Constrained RESTful Environments (OSCORE)
</title>
<author fullname="G. Selander" initials="G." surname="Selander"/>
<author fullname="J. Preuß Mattsson" initials="J." surname="Preuß Mattsson"/>
<author fullname="F. Palombini" initials="F." surname="Palombini"/>
<author fullname="L. Seitz" initials="L." surname="Seitz"/>
<date month="July" year="2019"/>
</front>
<seriesInfo name="RFC" value="8613"/>
<seriesInfo name="DOI" value="10.17487/RFC8613"/>
</reference>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8928.xml"
/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8929.xml"
/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9008.xml"
/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9010.xml"
/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9035.xml"
/>
<reference anchor="TIA-485-A" target="https://global.ihs.com/doc_detail.cf m?item_s_key=00032964"> <reference anchor="TIA-485-A" target="https://global.ihs.com/doc_detail.cf m?item_s_key=00032964">
<front> <front>
<title>TIA, "Electrical Characteristics of Generators and <title>Electrical Characteristics of Generators and Receivers for
Receivers for Use in Balanced Digital Multipoint Systems", Use in Balanced Digital Multipoint Systems</title>
TIA-485-A (Revision of TIA-485) <author>
</title> <organization>TIA</organization>
<author/> </author>
<date month="March" year="2003"/> <date month="March" year="1998"/>
</front> </front>
<refcontent>TIA-485-A, Revision of TIA-485</refcontent>
</reference> </reference>
<reference anchor="KW03" target="">
<reference anchor="KW03">
<front> <front>
<title>Karlof, Chris and Wagner, David, "Secure Routing in <title>Secure routing in wireless sensor networks: attacks and
Sensor Networks: Attacks and Countermeasures", countermeasures </title>
Elsevier's AdHoc Networks Journal, Special Issue on <author fullname="Chris Karlof" initials="C." surname="Karlof"/>
Sensor Network Applications and Protocols vol 1, <author fullname="David Wagner" initials="D." surname="Wagner"/>
issues 2-3
</title>
<author/>
<date month="September" year="2003"/> <date month="September" year="2003"/>
</front> </front>
<seriesInfo name="DOI" value="10.1016/S1570-8705(03)00008-8"/>
<refcontent>Volume 1, Issues 2-3, Pages 293-315</refcontent>
</reference> </reference>
<reference anchor="I-D.ietf-lake-edhoc" quoteTitle="true" target="https:
//datatracker.ietf.org/doc/html/draft-ietf-lake-edhoc-19" derivedAnchor="EDHOC"> <!-- [I-D.ietf-lake-edhoc] IESG state Publication Requested.
<front> Updated to long version because Mattsson's name is showing incorrectly.
<title>Ephemeral Diffie-Hellman Over COSE (EDHOC)</title> -->
<author fullname="Goran Selander" initials="G." surname="Selander">
<organization showOnFrontPage="true">Ericsson AB</organization> <reference anchor="I-D.ietf-lake-edhoc" target="https://datatracker.ietf.org/doc
</author> /html/draft-ietf-lake-edhoc-22">
<author fullname="John Mattsson" initials="J." surname="Mattsson"> <front>
<organization showOnFrontPage="tr <title>Ephemeral Diffie-Hellman Over COSE (EDHOC)</title>
ue">Ericsson AB</organization> <author initials="G." surname="Selander" fullname="Göran Selander">
</author> <organization>Ericsson AB</organization>
<author fullname="Francesca Palombini" initials="F." surname="Palomb </author>
ini"> <author initials="J." surname="Preuß Mattsson" fullname="John Preuß Mattsson">
<organization showOnFrontPage="true">Ericsson AB</organization> <organization>Ericsson AB</organization>
</author> </author>
<date day="3" month="February" year="2023"/> <author initials="F." surname="Palombini" fullname="Francesca Palombini">
</front> <organization>Ericsson AB</organization>
<seriesInfo name="Internet-Draft" value="draft-ietf-lake-edhoc-19"/> </author>
<refcontent>Work in Progress</refcontent> <date month="August" day="25" year="2023"/>
</reference> </front>
<reference anchor="BTCorev4.1" target="https://www.bluetooth.com/specifi <seriesInfo name="Internet-Draft" value="draft-ietf-lake-edhoc-22"/>
cations/specs/core-specification-4-1/"> </reference>
<reference anchor="BTCorev5.4" target="https://www.bluetooth.com/specifi
cations/specs/core-specification-5-4/">
<front> <front>
<title>Bluetooth Core Specification Version 4.1</title> <title>Core Specification Version 5.4</title>
<author> <author>
<organization>Bluetooth Special Interest Group</organization> <organization>Bluetooth</organization>
</author> </author>
<date year="2013" month="December"/> <date year="2012" month="January"/>
</front> </front>
</reference> </reference>
<reference anchor="IPSP" target="https://www.bluetooth.org/en-us/specifi
cation/adopted-specifications>."> <reference anchor="IPSP" target="https://www.bluetooth.com/specification
s/specs/internet-protocol-support-profile-1-0/">
<front> <front>
<title>Bluetooth Internet Protocol Support Profile Specification Ver sion 1.0.0</title> <title>Internet Protocol Support Profile 1.0</title>
<author> <author>
<organization>Bluetooth Special Interest Group</organization> <organization>Bluetooth</organization>
</author> </author>
<date year="2014" month="December"/> <date year="2014" month="December"/>
</front> </front>
</reference> </reference>
<reference anchor="TS102.939-1" target="https://w
ww.etsi.org/deliver/etsi_ts/102900_102999/10293901/01.02.01_60/ts_10293901v01020 <reference anchor="TS102.939-1" target="https://www.etsi.org/deliver/etsi
1p.pdf"> _ts/102900_102999/10293901/01.02.01_60/ts_10293901v010201p.pdf">
<front> <front>
<title>Digital Enhanced Cordless Telecommunications (DECT); Ultra Lo <title>Digital Enhanced Cordless Telecommunications (DECT); Ultra
w Energy (ULE); Machine to Machine Communications; Part 1: Home Automation Netwo Low Energy (ULE); Machine to Machine Communications; Part 1: Home
rk (phase 1) Automation Network (phase 1) </title>
</title>
<author> <author>
<organization>ETSI</organization> <organization>ETSI</organization>
</author> </author>
<date month="March" year="2015"/> <date month="March" year="2015"/>
</front> </front>
<seriesInfo name="Technical Specification" <seriesInfo name="ETSI-TS" value="102 939-1"/>
value="ETSI TS 102 939-1, V1.2.1"/> <refcontent>V1.2.1</refcontent>
</reference> </reference>
<reference anchor="TS102.939-2" target="https://www.etsi.
org/deliver/etsi_ts/102900_102999/10293902/01.01.01_60/ts_10293902v010101p.pdf"> <reference anchor="TS102.939-2" target="https://www.etsi.org/deliver/etsi
_ts/102900_102999/10293902/01.01.01_60/ts_10293902v010101p.pdf">
<front> <front>
<title>"Digital Enhanced Cordless Telecommunications (DECT); Ultra L <title>Digital Enhanced Cordless Telecommunications (DECT); Ultra
ow Energy (ULE); Machine to Machine Communications; Part 2: Home Automation Netw Low Energy (ULE); Machine to Machine Communications; Part 2: Home
ork (phase 2) Automation Network (phase 2)
</title> </title>
<author> <author>
<organization>ETSI</organization> <organization>ETSI</organization>
</author> </author>
<date month="March" year="2015"/> <date month="March" year="2015"/>
</front> </front>
<seriesInfo name="Technical Specification" <seriesInfo name="ETSI TS" value="102 939-2"/>
value="ETSI TS 102 939-2, V1.1.1"/> <refcontent>V1.1.1</refcontent>
</reference> </reference>
<reference anchor="LLCP-1.4" target="https://nfc-forum.org/build/specific
ations"> <reference anchor="LLCP-1.4" target="https://nfc-forum.org/build/specifications/
logical-link-control-protocol-technical-specification/">
<front> <front>
<title>NFC Logical Link Control Protocol, Version 1.4</title> <title>Logical Link Control Protocol Technical Specification</t
<author fullname="" initials="" surname="NFC Forum"/> itle>
<date month="January" year="2021"/> <author>
<organization>NFC Forum</organization>
</author>
<date month="December" year="2022"/>
</front> </front>
<seriesInfo name="NFC Forum Technical Specification" value=""/> <refcontent>Version 1.4</refcontent>
</reference> </reference>
<!-- </references>
&id.draft-winter-energy-efficient-internet; </references>
&id.draft-cheshire-edns0-owner-option;
<reference anchor='ITU'>
<front>
<title>Resolution 73 - Information and communication technologies an
d climate change</title>
<author></author>
<date month='October' year='2008' />
</front>
</reference>
<reference anchor='EPC'>
<front>
<title>The Case for Energy-Proportional Computing</title>
<author initials='L.' surname='Barroso' fullname='Luiz Andre Barroso
'></author>
<author initials='U.' surname='Holzle' fullname='Urs Holzle'></autho
r>
<date month='December' year='2007'/>
</front>
<seriesInfo name='Proc. IEEE International Conference on Network Protoco
ls (ICNP)' value=''/>
</reference>
<reference anchor='GreenSurvey'>
<front>
<title>A survey of green networking research</title>
<author initials='A.P.' surname='Bianzino' fullname='Aruna Prem Bian
zino'></author>
<author initials='C.' surname='Chaudet' fullname='Claude Chaudet'></
author>
<author initials='D.' surname='Rossi' fullname='Dario Rossi'></autho
r>
<author initials='J.-L.' surname='Rougier' fullname='Jean-Louis Roug
ier'></author> <date month='' year='2012' />
</front>
<seriesInfo name='IEEE Communications Surveys Tutorials' value='' />
</reference>
<reference anchor='EEE'>
<front>
<title>802.3az-2010</title>
<author></author>
<date month='' year='2010' />
</front>
<seriesInfo name='IEEE std' value='' />
</reference>
<reference anchor='PROXZZZY'> <section anchor="appendix-a" numbered="true" toc="default">
<front> <name>Design Space Dimensions for 6lo Deployment</name>
<title>ProxZZZy for sleeping hosts</title> <t><xref target="RFC6568" format="default"/> lists the dimensions used to
<author></author> describe the design space of wireless sensor networks in the context of the 6LoW
<date month='June' year='2012' /> PAN Working Group. The design space is already limited by the unique characteris
</front> tics of a LoWPAN (e.g., low power, short range, low bit rate).
<seriesInfo name='ECMA International' value='ECMA-393' />
</reference>
<reference anchor='EEEC'> In <xref target="RFC6568" sectionFormat="of" section="2"/>, the following design
<front> space dimensions are described: Deployment, Network Size, Power Source, Connect
<title>Improving the Energy Efficiency of Ethernet-Connected: ivity, Multi-Hop Communication, Traffic Pattern, Mobility, and Quality of Servic
A Proposal for Proxying</title> e (QoS). However, in this document, the following design space dimensions are co
<author initials='B.' surname='Nordman' fullname='Bbuce Nordman'></a nsidered:</t>
uthor> <dl spacing="normal" newline="true">
<author initials='K.' surname='Christensen' fullname='Ken Christense <dt>Deployment/Bootstrapping:</dt>
n'></author> <dd>6lo nodes can be connected randomly or in an organized manner. The
<date month='September' year='2007' /> bootstrapping has different characteristics for each link-layer
</front> technology.</dd>
<seriesInfo name='Ethernet Alliance' value='' /> <dt>Topology:</dt>
</reference> <dd>Topology of 6lo networks may inherently follow the characteristics
of each link-layer technology. Point-to-point, star, tree, or mesh
topologies can be configured, depending on the link-layer technology
considered.</dd>
<dt>L2-mesh or L3-mesh:</dt>
<dd>L2-mesh and L3-mesh may inherently follow the characteristics of
each link-layer technology. Some link-layer technologies may support
L2-mesh and some may not.</dd>
<dt>Multi-link Subnet and Single Subnet:</dt>
<dd>The selection of a multi-link subnet and a single subnet depends on
connectivity and the number of 6lo nodes.</dd>
<dt>Data Rate:</dt>
<dd>Typically, the link-layer technologies of 6lo have a low rate of
data transmission. However, by adjusting the MTU, it can deliver a higher
upper-layer data rate.</dd>
<dt>Buffering Requirements:</dt>
<reference anchor='NCP'> <dd>Some 6lo use case may require a higher data rate than the link-layer
<front> technology support. In this case, a buffering mechanism, telling the
<title>A Network Connection Proxy to Enable Hosts to Sleep and Save application to throttle its generation of data, and compression of the
Energy</title> data are possible to manage the data.</dd>
<author initials='M.' surname='Jimeno' fullname='M. Jimeno'></author <dt>Security and Privacy Requirements:</dt>
> <dd>Some 6lo use cases can involve transferring some important and
<author initials='K.' surname='Christensen' fullname='K. Christensen personal data between 6lo nodes. In this case, high-level security
'></author> support is required.</dd>
<author initials='B.' surname='Nordman' fullname='B. Nordman'></autho <dt>Mobility across 6lo Networks and Subnets:</dt>
r> <dd>The movement of 6lo nodes depends on the 6lo use case. If the 6lo
<date month='' year='2008' /> nodes can move or be moved around, a mobility management mechanism is
</front> required.</dd>
<seriesInfo name='Proc. IEEE Internat. Performance Computing and Communi <dt>Time Synchronization Requirements:</dt>
cations Conf' value='' /> <dd>The requirement of time synchronization of the upper-layer service
</reference> is dependent on the use case. For some 6lo use cases related to health
service, the measured data must be recorded with the exact time.</dd>
<dt>Reliability and QoS:</dt>
<dd>Some 6lo use cases require high reliability, for example,
real-time or health-related services.</dd>
<dt>Traffic Patterns:</dt>
<dd>6lo use cases may involve various traffic patterns. For example,
some 6lo use cases may require short data lengths and random
transmission. Some 6lo use cases may require continuous data
transmission and discontinuous data transmission.</dd>
<dt>Security Bootstrapping:</dt>
<dd>Without the external operations, 6lo nodes must have a security
bootstrapping mechanism. </dd>
<dt>Power Use Strategy:</dt>
<dd>To enable certain use cases, there may be requirements on the
class of energy availability and the strategy followed for using power
for communication <xref target="RFC7228" format="default"/>. Each link-la
yer technology defines a particular power use strategy that may be
tuned <xref target="RFC8352" format="default"/>. Readers are expected
to be familiar with the terminology found in <xref target="RFC7228"
format="default"/>.</dd>
<dt>Update Firmware Requirements:</dt>
<dd>Most 6lo use cases will need a mechanism to update firmware. In
these cases, support for over-the-air updates is required, probably in
a broadcast mode when bandwidth is low and the number of identical
devices is high.</dd>
<dt>Wired vs. Wireless:</dt>
<dd>Plenty of 6lo link-layer technologies are wireless, except MS/TP
and PLC. The selection of wired or wireless link-layer technology is
mainly dependent on the requirements of the 6lo use cases and the
characteristics of wired and wireless technologies.</dd>
</dl>
</section>
<reference anchor='SKILL'> <section anchor="Acknowledgements" numbered="false" toc="default">
<front> <name>Acknowledgements</name>
<title>Skilled in the Art of Being Idle: Reducing Energy Waste in Ne <t><contact fullname="Carles Gomez"/> has been funded in part by the
tworked Systems</title> Spanish Government through the Jose Castillejo CAS15/00336 grant, the
<author initials='S.' surname='Nedevschi' fullname='S. Nedevschi'></ TEC2016-79988-P grant, and the PID2019-106808RA-I00 grant as well as by
author> Secretaria d'Universitats i Recerca del Departament d'Empresa i
<author initials='J.' surname='Liu' fullname='J. Liu'></author> Coneixement de la Generalitat de Catalunya through grants 2017 SGR 376 and
<author initials='B.' surname='Nordman' fullname='B. Nord 2021 SGR 00330. His contribution to this work has been carried out in part duri
man'></author> ng
<author initials='S.' surname='Ratnasamy' fullname='S. Ratnas his stay as a visiting scholar at the Computer Laboratory of the
amy'></author> University of Cambridge. </t>
<author initials='N.' surname='Taft' fullname='N. Taft'>< <t><contact fullname="Thomas Watteyne"/>, <contact fullname="Pascal
/author> Thubert"/>, <contact fullname="Xavier Vilajosana"/>, <contact
<date month='' year='2009' /> fullname="Daniel Migault"/>, <contact fullname="Jianqiang Hou"/>,
</front> <contact fullname="Kerry Lynn"/>, <contact fullname="S.V.R. Anand"/>,
<seriesInfo name='Proc. USENIX Symposium on Networked Systems Design and and <contact fullname="Seyed Mahdi Darroudi"/> have provided valuable
Implementation' value='' /> feedback for this document.</t>
</reference> <t><contact fullname="Das Subir"/> and <contact fullname="Michel
--> Veillette"/> have provided valuable information of jupiterMesh, and
</references> <contact fullname="Paul Duffy"/> has provided valuable information of
</references> Wi-SUN for this document. Also, <contact fullname="Jianqiang Hou"/> has
<!-- Appendix Section A--> provided valuable information of G3-PLC and Netricity for this
<section numbered="true" toc="default"> document. <contact fullname="Take Aanstoot"/>, <contact fullname="Kerry
<name>Design Space Dimensions for 6lo Deployment</name> Lynn"/>, and <contact fullname="Dave Robin"/> have provided valuable
<t><xref target="RFC6568" format="default"/> lists the dimensions used to information of MS/TP and practical use case of MS/TP for this document.</t
describe the design space of wireless sensor networks in the context of the 6LoW >
PAN working group. The design space is already limited by the unique characteris <t><contact fullname="Deoknyong Ko"/> has provided relevant text of
tics of a LoWPAN (e.g., low power, short range, low bit rate). In <xref target=" LTE-MTC, and he shared his experience to deploy IPv6 and 6lo technologies
RFC6568" format="default"/>, the following design space dimensions are described over LTE MTC in SK Telecom.</t>
: Deployment, Network size, Power source, Connectivity, Multi-hop communication,
Traffic pattern, Mobility, Quality of Service (QoS). However, in this document,
the following design space dimensions are considered:</t>
<ul spacing="normal">
<li>Deployment/Bootstrapping: 6lo nodes can be connected randomly, or in
an organized manner. The bootstrapping has different characteristics for each l
ink layer technology.</li>
<li>Topology: Topology of 6lo networks may inherently follow the charact
eristics of each link layer technology. Point-to-point, star, tree or mesh topol
ogies can be configured, depending on the link layer technology considered.</li>
<li>L2-Mesh or L3-Mesh: L2-mesh and L3-mesh may inherently follow the ch
aracteristics of each link layer technology. Some link layer technologies may su
pport L2-mesh and some may not support.</li>
<li>Multi-link subnet, single subnet: The selection of multi-link subnet
and single subnet depends on connectivity and the number of 6lo nodes.</li>
<li>Data rate: Typically, the link layer technologies of 6lo have low ra
te of data transmission. But, by adjusting the MTU, it can deliver higher upper
layer data rate.</li>
<li>Buffering requirements: Some 6lo use case may require higher data ra
te than the link layer technology support. In this case, a buffering mechanism,
telling the application to throttle its generation of data, and compression of t
he data are possible to manage the data.</li>
<li>Security and Privacy Requirements: Some 6lo use case can involve tra
nsferring some important and personal data between 6lo nodes. In this case, high
-level security support is required.</li>
<li>Mobility across 6lo networks and subnets: The movement of 6lo nodes
depends on the 6lo use case. If the 6lo nodes can move or be moved around, a mob
ility management mechanism is required.</li>
<li>Time synchronization requirements: The requirement of time synchroni
zation of the upper layer service is dependent on the use case. For some 6lo use
case related to health service, the measured data must be recorded with exact t
ime.</li>
<li>Reliability and QoS: Some 6lo use case requires high reliability, fo
r example, real-time or health-related services.</li>
<li>Traffic patterns: 6lo use cases may involve various traffic patterns
. For example, some 6lo use cases may require short data lengths and random tra
nsmission. Some 6lo use case may require continuous data transmission and discon
tinuous data transmission.</li>
<li>Security Bootstrapping: Without the external operations, 6lo nodes m
ust have a security bootstrapping mechanism. </li>
<li>Power use strategy: to enable certain use cases, there may be requir
ements on the class of energy availability and the strategy followed for using p
ower for communication <xref target="RFC7228" format="default"/>. Each link laye
r technology defines a particular power use strategy which may be tuned <xref ta
rget="RFC8352" format="default"/>. Readers are expected to be familiar with <xre
f target="RFC7228" format="default"/> terminology.</li>
<li>Update firmware requirements: Most 6lo use cases will need a mechani
sm for updating firmware. In these cases, support for over the air updates is re
quired, probably in a broadcast mode when bandwidth is low and the number of ide
ntical devices is high.</li>
<li>Wired vs. Wireless: Plenty of 6lo link layer technologies are wirele
ss, except MS/TP and PLC. The selection of wired or wireless link layer technolo
gy is mainly dependent on the requirements of the 6lo use cases and the characte
ristics of wired/wireless technologies.</li>
</ul>
</section> </section>
</back> </back>
</rfc> </rfc>
 End of changes. 156 change blocks. 
1836 lines changed or deleted 1183 lines changed or added

This html diff was produced by rfcdiff 1.48.