<?xml version='1.0' encoding='utf-8'?>
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" version="3" submissionType="IETF" category="info" consensus="true" docName="draft-ietf-6lo-use-cases-16" number="9453" ipr="trust200902" obsoletes="" updates="" xml:lang="en" tocInclude="true" tocDepth="4" symRefs="true" sortRefs="true" prepTime="2023-09-21T12:41:10" indexInclude="true" scripts="Common,Latin">
  <link href="https://datatracker.ietf.org/doc/draft-ietf-6lo-use-cases-16" rel="prev"/>
  <link href="https://dx.doi.org/10.17487/rfc9453" rel="alternate"/>
  <link href="urn:issn:2070-1721" rel="alternate"/>
  <front>
    <title abbrev="6lo Applicability and Use Cases">Applicability and Use Cases for IPv6 over Networks of Resource-constrained Nodes (6lo)</title>
    <seriesInfo name="RFC" value="9453" stream="IETF"/>
    <author fullname="Yong-Geun Hong" initials="Y-G" surname="Hong">
      <organization showOnFrontPage="true">Daejeon University</organization>
      <address>
        <postal>
          <street>62 Daehak-ro, Dong-gu</street>
          <city>Daejeon</city>
          <region/>
          <code>34520</code>
          <country>South Korea</country>
        </postal>
        <phone>+82 42 280 4841</phone>
        <email>yonggeun.hong@gmail.com</email>
      </address>
    </author>
    <author initials="C." surname="Gomez" fullname="Carles Gomez">
      <organization abbrev="UPC" showOnFrontPage="true">Universitat Politecnica de Catalunya</organization>
      <address>
        <postal>
          <street>C/Esteve Terradas, 7</street>
          <code>08860</code>
          <city>Castelldefels</city>
          <country>Spain</country>
        </postal>
        <email>carles.gomez@upc.edu</email>
      </address>
    </author>
    <author fullname="Younghwan Choi" initials="Y." surname="Choi">
      <organization abbrev="ETRI" showOnFrontPage="true">ETRI</organization>
      <address>
        <postal>
          <street>218 Gajeongno, Yuseong</street>
          <city>Daejeon</city>
          <region/>
          <code>34129</code>
          <country>South Korea</country>
        </postal>
        <phone>+82 42 860 1429</phone>
        <email>yhc@etri.re.kr</email>
      </address>
    </author>
    <author fullname="Abdur Rashid Sangi" initials="A." surname="Sangi">
      <organization showOnFrontPage="true">Wenzhou-Kean University</organization>
      <address>
        <postal>
          <street>88 Daxue Road, Ouhai, Wenzhou</street>
          <city>Zhejiang</city>
          <region/>
          <code>325060</code>
          <country>China</country>
        </postal>
        <phone/>
        <email>sangi_bahrian@yahoo.com</email>
      </address>
    </author>
    <author fullname="Samita Chakrabarti" initials="S." surname="Chakrabarti">
      <organization showOnFrontPage="true">Verizon</organization>
      <address>
        <postal>
          <street/>
          <city>Bedminster</city>
          <region>NJ</region>
          <code/>
          <country>United States of America</country>
        </postal>
        <phone/>
        <email>samita.chakrabarti@verizon.com</email>
      </address>
    </author>
    <date month="09" year="2023"/>
    <area>int</area>
    <workgroup>6lo</workgroup>
    <abstract pn="section-abstract">
      <t indent="0" pn="section-abstract-1">This document describes the applicability of IPv6 over
      constrained-node networks (6lo) and provides practical deployment
      examples. In addition to IEEE Std 802.15.4, various link-layer
      technologies are used as examples, such as ITU-T G.9959 (Z-Wave),
      Bluetooth Low Energy (Bluetooth LE), Digital Enhanced Cordless Telecommunications
      - Ultra Low Energy (DECT-ULE), Master-Slave/Token Passing (MS/TP), Near
      Field Communication (NFC), and Power Line Communication (PLC). This
      document targets an audience who would like to understand and evaluate
      running end-to-end IPv6 over the constrained-node networks for local or
      Internet connectivity.</t>
    </abstract>
    <boilerplate>
      <section anchor="status-of-memo" numbered="false" removeInRFC="false" toc="exclude" pn="section-boilerplate.1">
        <name slugifiedName="name-status-of-this-memo">Status of This Memo</name>
        <t indent="0" pn="section-boilerplate.1-1">
            This document is not an Internet Standards Track specification; it is
            published for informational purposes.  
        </t>
        <t indent="0" pn="section-boilerplate.1-2">
            This document is a product of the Internet Engineering Task Force
            (IETF).  It represents the consensus of the IETF community.  It has
            received public review and has been approved for publication by the
            Internet Engineering Steering Group (IESG).  Not all documents
            approved by the IESG are candidates for any level of Internet
            Standard; see Section 2 of RFC 7841. 
        </t>
        <t indent="0" pn="section-boilerplate.1-3">
            Information about the current status of this document, any
            errata, and how to provide feedback on it may be obtained at
            <eref target="https://www.rfc-editor.org/info/rfc9453" brackets="none"/>.
        </t>
      </section>
      <section anchor="copyright" numbered="false" removeInRFC="false" toc="exclude" pn="section-boilerplate.2">
        <name slugifiedName="name-copyright-notice">Copyright Notice</name>
        <t indent="0" pn="section-boilerplate.2-1">
            Copyright (c) 2023 IETF Trust and the persons identified as the
            document authors. All rights reserved.
        </t>
        <t indent="0" pn="section-boilerplate.2-2">
            This document is subject to BCP 78 and the IETF Trust's Legal
            Provisions Relating to IETF Documents
            (<eref target="https://trustee.ietf.org/license-info" brackets="none"/>) in effect on the date of
            publication of this document. Please review these documents
            carefully, as they describe your rights and restrictions with
            respect to this document. Code Components extracted from this
            document must include Revised BSD License text as described in
            Section 4.e of the Trust Legal Provisions and are provided without
            warranty as described in the Revised BSD License.
        </t>
      </section>
    </boilerplate>
    <toc>
      <section anchor="toc" numbered="false" removeInRFC="false" toc="exclude" pn="section-toc.1">
        <name slugifiedName="name-table-of-contents">Table of Contents</name>
        <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1">
          <li pn="section-toc.1-1.1">
            <t indent="0" keepWithNext="true" pn="section-toc.1-1.1.1"><xref derivedContent="1" format="counter" sectionFormat="of" target="section-1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-introduction">Introduction</xref></t>
          </li>
          <li pn="section-toc.1-1.2">
            <t indent="0" pn="section-toc.1-1.2.1"><xref derivedContent="2" format="counter" sectionFormat="of" target="section-2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-6lo-link-layer-technologies">6lo Link-Layer Technologies</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.2.2">
              <li pn="section-toc.1-1.2.2.1">
                <t indent="0" keepWithNext="true" pn="section-toc.1-1.2.2.1.1"><xref derivedContent="2.1" format="counter" sectionFormat="of" target="section-2.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-itu-t-g9959">ITU-T G.9959</xref></t>
              </li>
              <li pn="section-toc.1-1.2.2.2">
                <t indent="0" keepWithNext="true" pn="section-toc.1-1.2.2.2.1"><xref derivedContent="2.2" format="counter" sectionFormat="of" target="section-2.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-bluetooth-le">Bluetooth LE</xref></t>
              </li>
              <li pn="section-toc.1-1.2.2.3">
                <t indent="0" pn="section-toc.1-1.2.2.3.1"><xref derivedContent="2.3" format="counter" sectionFormat="of" target="section-2.3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-dect-ule">DECT-ULE</xref></t>
              </li>
              <li pn="section-toc.1-1.2.2.4">
                <t indent="0" pn="section-toc.1-1.2.2.4.1"><xref derivedContent="2.4" format="counter" sectionFormat="of" target="section-2.4"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-ms-tp">MS/TP</xref></t>
              </li>
              <li pn="section-toc.1-1.2.2.5">
                <t indent="0" pn="section-toc.1-1.2.2.5.1"><xref derivedContent="2.5" format="counter" sectionFormat="of" target="section-2.5"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-nfc">NFC</xref></t>
              </li>
              <li pn="section-toc.1-1.2.2.6">
                <t indent="0" pn="section-toc.1-1.2.2.6.1"><xref derivedContent="2.6" format="counter" sectionFormat="of" target="section-2.6"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-plc">PLC</xref></t>
              </li>
              <li pn="section-toc.1-1.2.2.7">
                <t indent="0" pn="section-toc.1-1.2.2.7.1"><xref derivedContent="2.7" format="counter" sectionFormat="of" target="section-2.7"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-comparison-between-6lo-link">Comparison between 6lo Link-Layer Technologies</xref></t>
              </li>
            </ul>
          </li>
          <li pn="section-toc.1-1.3">
            <t indent="0" pn="section-toc.1-1.3.1"><xref derivedContent="3" format="counter" sectionFormat="of" target="section-3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-guidelines-for-adopting-an-">Guidelines for Adopting an IPv6 Stack (6lo)</xref></t>
          </li>
          <li pn="section-toc.1-1.4">
            <t indent="0" pn="section-toc.1-1.4.1"><xref derivedContent="4" format="counter" sectionFormat="of" target="section-4"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-6lo-deployment-examples">6lo Deployment Examples</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.4.2">
              <li pn="section-toc.1-1.4.2.1">
                <t indent="0" pn="section-toc.1-1.4.2.1.1"><xref derivedContent="4.1" format="counter" sectionFormat="of" target="section-4.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-wi-sun-usage-of-6lo-in-netw">Wi-SUN Usage of 6lo in Network Layer</xref></t>
              </li>
              <li pn="section-toc.1-1.4.2.2">
                <t indent="0" pn="section-toc.1-1.4.2.2.1"><xref derivedContent="4.2" format="counter" sectionFormat="of" target="section-4.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-thread-usage-of-6lo-in-the-">Thread Usage of 6lo in the Network Layer</xref></t>
              </li>
              <li pn="section-toc.1-1.4.2.3">
                <t indent="0" pn="section-toc.1-1.4.2.3.1"><xref derivedContent="4.3" format="counter" sectionFormat="of" target="section-4.3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-g3-plc-usage-of-6lo-in-netw">G3-PLC Usage of 6lo in Network Layer</xref></t>
              </li>
              <li pn="section-toc.1-1.4.2.4">
                <t indent="0" pn="section-toc.1-1.4.2.4.1"><xref derivedContent="4.4" format="counter" sectionFormat="of" target="section-4.4"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-netricity-usage-of-6lo-in-t">Netricity Usage of 6lo in the Network Layer</xref></t>
              </li>
            </ul>
          </li>
          <li pn="section-toc.1-1.5">
            <t indent="0" pn="section-toc.1-1.5.1"><xref derivedContent="5" format="counter" sectionFormat="of" target="section-5"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-6lo-use-case-examples">6lo Use-Case Examples</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.5.2">
              <li pn="section-toc.1-1.5.2.1">
                <t indent="0" pn="section-toc.1-1.5.2.1.1"><xref derivedContent="5.1" format="counter" sectionFormat="of" target="section-5.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-use-case-of-itu-t-g9959-sma">Use Case of ITU-T G.9959: Smart Home</xref></t>
              </li>
              <li pn="section-toc.1-1.5.2.2">
                <t indent="0" pn="section-toc.1-1.5.2.2.1"><xref derivedContent="5.2" format="counter" sectionFormat="of" target="section-5.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-use-case-of-bluetooth-le-sm">Use Case of Bluetooth LE: Smartphone-Based Interaction</xref></t>
              </li>
              <li pn="section-toc.1-1.5.2.3">
                <t indent="0" pn="section-toc.1-1.5.2.3.1"><xref derivedContent="5.3" format="counter" sectionFormat="of" target="section-5.3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-use-case-of-dect-ule-smart-">Use Case of DECT-ULE: Smart Home</xref></t>
              </li>
              <li pn="section-toc.1-1.5.2.4">
                <t indent="0" pn="section-toc.1-1.5.2.4.1"><xref derivedContent="5.4" format="counter" sectionFormat="of" target="section-5.4"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-use-case-of-ms-tp-building-">Use Case of MS/TP: Building Automation Networks</xref></t>
              </li>
              <li pn="section-toc.1-1.5.2.5">
                <t indent="0" pn="section-toc.1-1.5.2.5.1"><xref derivedContent="5.5" format="counter" sectionFormat="of" target="section-5.5"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-use-case-of-nfc-alternative">Use Case of NFC: Alternative Secure Transfer</xref></t>
              </li>
              <li pn="section-toc.1-1.5.2.6">
                <t indent="0" pn="section-toc.1-1.5.2.6.1"><xref derivedContent="5.6" format="counter" sectionFormat="of" target="section-5.6"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-use-case-of-plc-smart-grid">Use Case of PLC: Smart Grid</xref></t>
              </li>
            </ul>
          </li>
          <li pn="section-toc.1-1.6">
            <t indent="0" pn="section-toc.1-1.6.1"><xref derivedContent="6" format="counter" sectionFormat="of" target="section-6"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-iana-considerations">IANA Considerations</xref></t>
          </li>
          <li pn="section-toc.1-1.7">
            <t indent="0" pn="section-toc.1-1.7.1"><xref derivedContent="7" format="counter" sectionFormat="of" target="section-7"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-security-considerations">Security Considerations</xref></t>
          </li>
          <li pn="section-toc.1-1.8">
            <t indent="0" pn="section-toc.1-1.8.1"><xref derivedContent="8" format="counter" sectionFormat="of" target="section-8"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-references">References</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.8.2">
              <li pn="section-toc.1-1.8.2.1">
                <t indent="0" pn="section-toc.1-1.8.2.1.1"><xref derivedContent="8.1" format="counter" sectionFormat="of" target="section-8.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-normative-references">Normative References</xref></t>
              </li>
              <li pn="section-toc.1-1.8.2.2">
                <t indent="0" pn="section-toc.1-1.8.2.2.1"><xref derivedContent="8.2" format="counter" sectionFormat="of" target="section-8.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-informative-references">Informative References</xref></t>
              </li>
            </ul>
          </li>
          <li pn="section-toc.1-1.9">
            <t indent="0" pn="section-toc.1-1.9.1"><xref derivedContent="Appendix A" format="default" sectionFormat="of" target="section-appendix.a"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-design-space-dimensions-for">Design Space Dimensions for 6lo Deployment</xref></t>
          </li>
          <li pn="section-toc.1-1.10">
            <t indent="0" pn="section-toc.1-1.10.1"><xref derivedContent="" format="none" sectionFormat="of" target="section-appendix.b"/><xref derivedContent="" format="title" sectionFormat="of" target="name-acknowledgements">Acknowledgements</xref></t>
          </li>
          <li pn="section-toc.1-1.11">
            <t indent="0" pn="section-toc.1-1.11.1"><xref derivedContent="" format="none" sectionFormat="of" target="section-appendix.c"/><xref derivedContent="" format="title" sectionFormat="of" target="name-authors-addresses">Authors' Addresses</xref></t>
          </li>
        </ul>
      </section>
    </toc>
  </front>
  <middle>
    <section numbered="true" toc="include" removeInRFC="false" pn="section-1">
      <name slugifiedName="name-introduction">Introduction</name>
      <t indent="0" pn="section-1-1">Running IPv6 on constrained-node networks presents challenges due to
      the characteristics of these networks, such as small packet size, low
      power, low bandwidth, and large number of devices, among others <xref target="RFC4919" format="default" sectionFormat="of" derivedContent="RFC4919"/> <xref target="RFC7228" format="default" sectionFormat="of" derivedContent="RFC7228"/>. For example, many IEEE Std 802.15.4 variants <xref target="IEEE-802.15.4" format="default" sectionFormat="of" derivedContent="IEEE-802.15.4"/> exhibit a frame size of 127
      octets, whereas IPv6 requires its underlying layer to support an MTU of
      1280 bytes. Furthermore, those IEEE Std 802.15.4 variants do not offer
      fragmentation and reassembly functionality. (It is noted that IEEE Std
      802.15.9-2021 provides a multiplexing and fragmentation layer for the
      IEEE Std 802.15.4 <xref target="IEEE-802.15.9" format="default" sectionFormat="of" derivedContent="IEEE-802.15.9"/>.)
      Therefore, an appropriate adaptation layer supporting fragmentation and
      reassembly must be provided below IPv6. Also, the limited IEEE Std
      802.15.4 frame size and low energy consumption requirements motivate the
      need for packet header compression. The IETF IPv6 over Low-Power
      Wireless Personal Area Network (6LoWPAN) Working Group published a suite
      of specifications that provides an adaptation layer to support IPv6 over
      IEEE Std 802.15.4 comprising the following functionalities: </t>
      <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-1-2">
        <li pn="section-1-2.1">fragmentation and reassembly, address autoconfiguration, and a
        frame format <xref target="RFC4944" format="default" sectionFormat="of" derivedContent="RFC4944"/></li>
        <li pn="section-1-2.2">IPv6 (and UDP) header compression <xref target="RFC6282" format="default" sectionFormat="of" derivedContent="RFC6282"/></li>
        <li pn="section-1-2.3">Neighbor Discovery Optimization for 6LoWPAN <xref target="RFC6775" format="default" sectionFormat="of" derivedContent="RFC6775"/> <xref target="RFC8505" format="default" sectionFormat="of" derivedContent="RFC8505"/></li>
      </ul>
      <t indent="0" pn="section-1-3">As Internet of Things (IoT) services become more popular, the IETF has defined adaptation layer functionality to support IPv6 over various link-layer technologies other than IEEE Std 802.15.4, such as Bluetooth Low Energy (Bluetooth LE), ITU-T G.9959 (Z-Wave), Digital Enhanced Cordless Telecommunications - Ultra Low Energy (DECT-ULE), Master-Slave/Token Passing (MS/TP), Near Field Communication (NFC), and Power Line Communication (PLC). The 6lo adaptation layers use a variation of the 6LoWPAN stack applied to each particular link-layer technology.</t>
      <t indent="0" pn="section-1-4">The 6LoWPAN Working Group produced the document entitled "<xref target="RFC6568" format="title" sectionFormat="of" derivedContent="Design and Application Spaces for IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs)"/>" <xref target="RFC6568" format="default" sectionFormat="of" derivedContent="RFC6568"/>, which describes potential application scenarios and
      use cases for LoWPANs. The present document aims to provide guidance to
      an audience that is new to the IPv6 over constrained-node networks (6lo)
      concept and want to assess its application to the constrained-node
      network of their interest. This 6lo applicability document describes a
      few sets of practical 6lo deployment scenarios and use-case
      examples. In addition, it considers various network design space
      dimensions, such as Deployment, Network Size, Power Source,
      Connectivity, Multi-Hop Communication, Traffic pattern,
      Mobility, and QoS requirements (see <xref target="appendix-a" format="default" sectionFormat="of" derivedContent="Appendix A"/>).
</t>
      <t indent="0" pn="section-1-5">This document provides the applicability and use cases of 6lo,
      considering the following aspects:</t>
      <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-1-6">
        <li pn="section-1-6.1">Various IoT-related wired or wireless link-layer technologies
        providing practical information about such technologies.</li>
        <li pn="section-1-6.2">General guidelines on how the 6LoWPAN stack can be modified for a
        given L2 technology.</li>
        <li pn="section-1-6.3">Various 6lo use cases and practical deployment examples.</li>
      </ul>
      <t indent="0" pn="section-1-7">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="default" sectionFormat="of" derivedContent="TIA-485-A"/> and <xref target="BACnet" format="default" sectionFormat="of" derivedContent="BACnet"/>).</t>
    </section>
    <section anchor="sec2" numbered="true" toc="include" removeInRFC="false" pn="section-2">
      <name slugifiedName="name-6lo-link-layer-technologies">6lo Link-Layer Technologies</name>
      <section numbered="true" toc="include" removeInRFC="false" pn="section-2.1">
        <name slugifiedName="name-itu-t-g9959">ITU-T G.9959</name>
        <t indent="0" pn="section-2.1-1">The ITU-T G.9959 Recommendation <xref target="G.9959" format="default" sectionFormat="of" derivedContent="G.9959"/> targets LoWPANs and defines physical-layer and link-layer functionality. Physical layers of 9.6 kbit/s, 40 kbit/s, and 100
        kbit/s are supported. <br/><xref target="G.9959" format="default" sectionFormat="of" derivedContent="G.9959"/> defines
        how a unique 32-bit HomeID network identifier is assigned by a network
        controller and how an 8-bit NodeID host identifier is allocated to
        each node. NodeIDs are unique within the network identified by the
        HomeID.  The G.9959 HomeID represents an IPv6 subnet that is
        identified by one or more IPv6 prefixes <xref target="RFC7428" format="default" sectionFormat="of" derivedContent="RFC7428"/>. ITU-T G.9959 can be used for smart home
        applications, and the transmission range is 100 meters per hop.</t>
      </section>
      <section numbered="true" toc="include" removeInRFC="false" pn="section-2.2">
        <name slugifiedName="name-bluetooth-le">Bluetooth LE</name>
        <t indent="0" pn="section-2.2-1">Bluetooth LE was introduced in Bluetooth 4.0, enhanced in Bluetooth 4.1, and developed further in successive versions. The data rate of Bluetooth LE is 125 kb/s, 500 kb/s, 1 Mb/s, 2 Mb/s; and max transmission range is around 100 meters (outdoors). The Bluetooth Special Interest Group (Bluetooth SIG) has also published the Internet Protocol Support Profile (IPSP). The IPSP enables discovery of IP-enabled devices and establishment of link-layer connections for transporting IPv6 packets. IPv6 over Bluetooth LE is dependent on both Bluetooth 4.1 <xref target="BTCorev5.4" format="default" sectionFormat="of" derivedContent="BTCorev5.4"/> and IPSP 1.0 <xref target="IPSP" format="default" sectionFormat="of" derivedContent="IPSP"/> or newer.</t>
        <t indent="0" pn="section-2.2-2">Many devices such as mobile phones, notebooks, tablets, and other handheld computing devices that support Bluetooth 4.0 or subsequent versions also support the low-energy variant of Bluetooth. Bluetooth LE is also being included in many different types of accessories that collaborate with mobile devices. An example of a use case for a Bluetooth LE accessory is a heart rate monitor that sends data via the mobile phone to a server on the Internet <xref target="RFC7668" format="default" sectionFormat="of" derivedContent="RFC7668"/>. A typical usage of Bluetooth LE is smartphone-based interaction with constrained devices. Bluetooth LE was originally designed to enable star topology networks.  However, recent Bluetooth versions support the formation of extended topologies, and IPv6 support for mesh networks of Bluetooth LE devices has been developed <xref target="RFC9159" format="default" sectionFormat="of" derivedContent="RFC9159"/>.</t>
      </section>
      <section numbered="true" toc="include" removeInRFC="false" pn="section-2.3">
        <name slugifiedName="name-dect-ule">DECT-ULE</name>
        <t indent="0" pn="section-2.3-1">DECT-ULE is a low-power air interface technology that is designed to support both circuit-switched services, such as voice communication, and packet-mode data services at modest data rate <xref target="TS102.939-1" format="default" sectionFormat="of" derivedContent="TS102.939-1"/> <xref target="TS102.939-2" format="default" sectionFormat="of" derivedContent="TS102.939-2"/>.</t>
        <t indent="0" pn="section-2.3-2">The DECT-ULE protocol stack consists of the physical layer operating at frequencies in the dedicated 1880 - 1920 MHz frequency band depending on the region and uses a symbol rate of 1.152 Mbps. Radio bearers are allocated by use of Frequency-Division Multiplex (FDMA), Time-Division Multiple Access (TDMA), and Time-Division Duplex (TDD) techniques. The coverage distance is from 70 meters (indoors) to 600 meters (outdoors).</t>
        <t indent="0" pn="section-2.3-3">In its generic network topology, DECT is defined as a cellular network technology. However, the most common configuration is a star network with a single Fixed Part (FP) defining the network with a number of Portable Parts (PPs) attached. The Medium Access Control (MAC) layer supports classical DECT as this is used for services like discovery, pairing, and security features. All these features have been reused from DECT.</t>
        <t indent="0" pn="section-2.3-4">The DECT-ULE device can switch to the ULE mode of operation, utilizing the new Ultra Low Energy (ULE) MAC layer features. The DECT-ULE Data Link Control (DLC) provides multiplexing as well as segmentation and re-assembly for larger packets from layers above.  The DECT-ULE layer also implements per-message authentication and encryption. The DLC layer ensures packet integrity and preserves packet order, but delivery is based on best effort.</t>
        <t indent="0" pn="section-2.3-5">The current DECT-ULE MAC layer standard supports low bandwidth data broadcast. However, the usage of this broadcast service has not yet been standardized for higher layers <xref target="RFC8105" format="default" sectionFormat="of" derivedContent="RFC8105"/>. DECT-ULE can be used for smart metering in a home.</t>
      </section>
      <section numbered="true" toc="include" removeInRFC="false" pn="section-2.4">
        <name slugifiedName="name-ms-tp">MS/TP</name>
        <t indent="0" pn="section-2.4-1">MS/TP is a MAC protocol for the RS-485 <xref target="TIA-485-A" format="default" sectionFormat="of" derivedContent="TIA-485-A"/> physical layer and is used primarily in building automation networks.</t>
        <t indent="0" pn="section-2.4-2">An MS/TP device is typically based on a low-cost microcontroller with
   limited processing power and memory.  These constraints, together with low data rates and a small MAC address space, are similar to those faced in 6LoWPAN networks.  MS/TP differs significantly from 6LoWPAN in at least three respects:</t>
        <ol spacing="normal" type="a" indent="adaptive" start="1" pn="section-2.4-3">
     <li pn="section-2.4-3.1" derivedCounter="a.">MS/TP devices are typically mains powered.</li>
          <li pn="section-2.4-3.2" derivedCounter="b.">All MS/TP devices on a segment can communicate directly, so there are
     no hidden node issues or mesh routing issues.</li>
          <li pn="section-2.4-3.3" derivedCounter="c.">The latest MS/TP specification provides support for large payloads,
     eliminating the need for fragmentation and reassembly below
     IPv6.</li>
        </ol>
        <t indent="0" pn="section-2.4-4">MS/TP is designed to enable multidrop networks over shielded twisted pair wiring. It can support network segments up to 1000 meters in length at a data rate of 115.2 kbit/s or segments up to 1200 meters in length at lower bit rates. An MS/TP interface requires only a Universal Asynchronous Receiver Transmitter (UART), an RS-485 <xref target="TIA-485-A" format="default" sectionFormat="of" derivedContent="TIA-485-A"/> transceiver with a driver that can be disabled, and a 5 ms resolution timer.  The MS/TP MAC is typically implemented in software.</t>
        <t indent="0" pn="section-2.4-5">Because of its long range (~1 km), MS/TP can be used to connect remote devices (such as district heating controllers) to the nearest building control infrastructure over a single link <xref target="RFC8163" format="default" sectionFormat="of" derivedContent="RFC8163"/>. </t>
      </section>
      <section numbered="true" toc="include" removeInRFC="false" pn="section-2.5">
        <name slugifiedName="name-nfc">NFC</name>
        <t indent="0" pn="section-2.5-1">NFC technology enables secure interactions between electronic devices, allowing consumers to perform contactless transactions, access digital content, and connect electronic devices with a single touch <xref target="LLCP-1.4" format="default" sectionFormat="of" derivedContent="LLCP-1.4"/>. The distance between sender and receiver is 10 cm or less. NFC complements many popular consumer-level wireless technologies by utilizing the key elements in existing standards for contactless card technology.</t>
        <t indent="0" pn="section-2.5-2">Extending the capability of contactless card technology, NFC also
        enables devices to share information at a distance that is less than
        10 cm with a maximum communication speed of 424 kbps. Users can share
        business cards, make transactions, access information from a smart
        poster, or provide credentials for access control systems with a
        simple touch.</t>
        <t indent="0" pn="section-2.5-3">NFC's bidirectional communication ability is suitable for establishing connections with other technologies by the simplicity of touch. In addition to the easy connection and quick transactions, simple data sharing is available <xref target="RFC9428" format="default" sectionFormat="of" derivedContent="RFC9428"/>. NFC can be used for secure transfer services where privacy is important.</t>
      </section>
      <section numbered="true" toc="include" removeInRFC="false" pn="section-2.6">
        <name slugifiedName="name-plc">PLC</name>
        <t indent="0" pn="section-2.6-1">PLC is a data transmission technique that utilizes power conductors as the medium <xref target="RFC9354" format="default" sectionFormat="of" derivedContent="RFC9354"/>. Unlike other dedicated communication infrastructure, power conductors are widely available indoors and outdoors. Moreover, wired technologies cause less interference to the radio medium than wireless technologies and are more reliable than their wireless counterparts.</t>
        <t indent="0" pn="section-2.6-2">The table below shows some available open standards defining PLC.</t>
        <table anchor="table_PLC" align="center" pn="table-1">
          <name slugifiedName="name-some-available-open-standar">Some Available Open Standards in PLC</name>
          <thead>
            <tr>
              <th align="center" colspan="1" rowspan="1">PLC Systems</th>
              <th align="center" colspan="1" rowspan="1">Frequency Range</th>
              <th align="center" colspan="1" rowspan="1">Type</th>
              <th align="center" colspan="1" rowspan="1">Data Rate</th>
              <th align="center" colspan="1" rowspan="1">Distance</th>
            </tr>
          </thead>
          <tbody>
            <tr>
              <td align="center" colspan="1" rowspan="1">IEEE 1901</td>
              <td align="center" colspan="1" rowspan="1">&lt; 100 MHz</td>
              <td align="center" colspan="1" rowspan="1">Broadband</td>
              <td align="center" colspan="1" rowspan="1">200 Mbps</td>
              <td align="center" colspan="1" rowspan="1">1000 m</td>
            </tr>
            <tr>
              <td align="center" colspan="1" rowspan="1">IEEE 1901.1</td>
              <td align="center" colspan="1" rowspan="1">&lt; 12 MHz</td>
              <td align="center" colspan="1" rowspan="1">PLC-IoT</td>
              <td align="center" colspan="1" rowspan="1">10 Mbps</td>
              <td align="center" colspan="1" rowspan="1">2000 m</td>
            </tr>
            <tr>
              <td align="center" colspan="1" rowspan="1">IEEE 1901.2</td>
              <td align="center" colspan="1" rowspan="1">&lt; 500 kHz</td>
              <td align="center" colspan="1" rowspan="1">Narrowband</td>
              <td align="center" colspan="1" rowspan="1">200 kbps</td>
              <td align="center" colspan="1" rowspan="1">3000 m</td>
            </tr>
            <tr>
              <td align="center" colspan="1" rowspan="1">G3-PLC</td>
              <td align="center" colspan="1" rowspan="1">&lt; 500 kHz</td>
              <td align="center" colspan="1" rowspan="1">Narrowband</td>
              <td align="center" colspan="1" rowspan="1">234 kbps</td>
              <td align="center" colspan="1" rowspan="1">3000 m</td>
            </tr>
          </tbody>
        </table>
        <t indent="0" pn="section-2.6-4">IEEE Std 1901 <xref target="IEEE-1901" format="default" sectionFormat="of" derivedContent="IEEE-1901"/> defines a broadband variant of PLC, but it is only effective within short range. This standard addresses the requirements of high data rates such as the Internet, HDTV, audio, and gaming.</t>
        <t indent="0" pn="section-2.6-5">IEEE Std 1901.1 <xref target="IEEE-1901.1" format="default" sectionFormat="of" derivedContent="IEEE-1901.1"/> defines a medium frequency band (less than 12 MHz) broadband PLC technology for smart grid applications based on Orthogonal Frequency Division Multiplexing (OFDM). By achieving an extended communication range with medium speeds, this standard can be applied in both indoor and outdoor scenarios, such as Advanced Metering Infrastructure (AMI), street lighting, electric vehicle charging, and a smart city.</t>
        <t indent="0" pn="section-2.6-6">IEEE Std 1901.2 <xref target="IEEE-1901.2" format="default" sectionFormat="of" derivedContent="IEEE-1901.2"/> defines a narrowband variant of PLC with a lower data rate but a significantly higher transmission range that could be used in an indoor or even an outdoor environment. A typical use case of PLC is a smart grid.</t>
        <t indent="0" pn="section-2.6-7">G3-PLC <xref target="G3-PLC" format="default" sectionFormat="of" derivedContent="G3-PLC"/> is a narrowband PLC technology that is based on the ITU-T G.9903 Recommendation <xref target="G.9903" format="default" sectionFormat="of" derivedContent="G.9903"/>. The ITU-T G.9903 Recommendation contains the physical layer and data link-layer specification for the G3-PLC narrowband OFDM power line communication transceivers, for communications via alternating current and direct current electric power lines over frequency bands below 500 kHz.</t>
      </section>
      <section numbered="true" toc="include" removeInRFC="false" pn="section-2.7">
        <name slugifiedName="name-comparison-between-6lo-link">Comparison between 6lo Link-Layer Technologies</name>
        <t indent="0" pn="section-2.7-1">In the above subsections, various 6lo link-layer technologies are described. The following table shows the dominant parameters of each use case corresponding to the 6lo link-layer technology.</t>
        <table anchor="table2" align="center" pn="table-2">
          <name slugifiedName="name-comparison-between-6lo-link-">Comparison between 6lo Link-Layer Technologies</name>
          <thead>
            <tr>
              <th align="left" colspan="1" rowspan="1"/>
              <th align="center" colspan="1" rowspan="1">Z-Wave</th>
              <th align="center" colspan="1" rowspan="1">Bluetooth LE</th>
              <th align="center" colspan="1" rowspan="1">DECT-ULE</th>
              <th align="center" colspan="1" rowspan="1">MS/TP</th>
              <th align="center" colspan="1" rowspan="1">NFC</th>
              <th align="center" colspan="1" rowspan="1">PLC</th>
            </tr>
          </thead>
          <tbody>
            <tr>
              <th align="center" colspan="1" rowspan="1">Usage</th>
              <td align="center" colspan="1" rowspan="1">Home Autom.</td>
              <td align="center" colspan="1" rowspan="1">Interact w/ Smart Phone</td>
              <td align="center" colspan="1" rowspan="1">Meter Reading</td>
              <td align="center" colspan="1" rowspan="1">Building Autom.</td>
              <td align="center" colspan="1" rowspan="1">Secure Transfer</td>
              <td align="center" colspan="1" rowspan="1">Smart Grid</td>
            </tr>
            <tr>
              <th align="center" colspan="1" rowspan="1">Topology<br/>&amp;<br/>Subnet</th>
              <td align="center" colspan="1" rowspan="1">L2-mesh<br/>or<br/>L3-mesh</td>
              <td align="center" colspan="1" rowspan="1">Star &amp; Mesh</td>
              <td align="center" colspan="1" rowspan="1">Star, No mesh</td>
              <td align="center" colspan="1" rowspan="1">MS/TP, No mesh</td>
              <td align="center" colspan="1" rowspan="1">P2P, L2‑mesh</td>
              <td align="center" colspan="1" rowspan="1">Star Tree Mesh</td>
            </tr>
            <tr>
              <th align="center" colspan="1" rowspan="1">Mobility Req.</th>
              <td align="center" colspan="1" rowspan="1">No</td>
              <td align="center" colspan="1" rowspan="1">Yes</td>
              <td align="center" colspan="1" rowspan="1">No</td>
              <td align="center" colspan="1" rowspan="1">No</td>
              <td align="center" colspan="1" rowspan="1">Yes</td>
              <td align="center" colspan="1" rowspan="1">No</td>
            </tr>
            <tr>
              <th align="center" colspan="1" rowspan="1">Buffering Req.</th>
              <td align="center" colspan="1" rowspan="1">Yes</td>
              <td align="center" colspan="1" rowspan="1">Yes</td>
              <td align="center" colspan="1" rowspan="1">Yes</td>
              <td align="center" colspan="1" rowspan="1">Yes</td>
              <td align="center" colspan="1" rowspan="1">Yes</td>
              <td align="center" colspan="1" rowspan="1">Yes</td>
            </tr>
            <tr>
              <th align="center" colspan="1" rowspan="1">Latency,<br/>QoS Req.</th>
              <td align="center" colspan="1" rowspan="1">Yes</td>
              <td align="center" colspan="1" rowspan="1">Yes</td>
              <td align="center" colspan="1" rowspan="1">Yes</td>
              <td align="center" colspan="1" rowspan="1">Yes</td>
              <td align="center" colspan="1" rowspan="1">Yes</td>
              <td align="center" colspan="1" rowspan="1">Yes</td>
            </tr>
            <tr>
              <th align="center" colspan="1" rowspan="1">Frequent<br/>Tx Req.</th>
              <td align="center" colspan="1" rowspan="1">No</td>
              <td align="center" colspan="1" rowspan="1">No</td>
              <td align="center" colspan="1" rowspan="1">No</td>
              <td align="center" colspan="1" rowspan="1">Yes</td>
              <td align="center" colspan="1" rowspan="1">No</td>
              <td align="center" colspan="1" rowspan="1">No</td>
            </tr>
            <tr>
              <th align="center" colspan="1" rowspan="1">RFC</th>
              <td align="center" colspan="1" rowspan="1">RFC 7428</td>
              <td align="center" colspan="1" rowspan="1">RFC 7668<br/>RFC 9159</td>
              <td align="center" colspan="1" rowspan="1">RFC 8105</td>
              <td align="center" colspan="1" rowspan="1">RFC 8163</td>
              <td align="center" colspan="1" rowspan="1">RFC 9428</td>
              <td align="center" colspan="1" rowspan="1">RFC 9354</td>
            </tr>
          </tbody>
        </table>
      </section>
    </section>
    <section numbered="true" toc="include" removeInRFC="false" pn="section-3">
      <name slugifiedName="name-guidelines-for-adopting-an-">Guidelines for Adopting an IPv6 Stack (6lo)</name>
      <t indent="0" pn="section-3-1">6lo aims to reuse and/or adapt existing 6LoWPAN functionality in
      order to efficiently support IPv6 over a variety of IoT L2
      technologies. The following guideline targets new candidate-constrained
      L2 technologies that may be considered for running a modified 6LoWPAN
      stack on top. The modification of the 6LoWPAN stack should be based on
      the following:</t>
      <dl spacing="normal" newline="true" indent="3" pn="section-3-2">
        <dt pn="section-3-2.1">Addressing Model:</dt>
        <dd pn="section-3-2.2">The addressing model determines whether the device is capable of
	forming IPv6 link-local and global addresses, and what is the best way
	to derive the IPv6 addresses for the constrained L2
	devices. IPv6 addresses that are derived from an L2 address are specified in <xref target="RFC4944" format="default" sectionFormat="of" derivedContent="RFC4944"/>, but there are implications for
	privacy. The reason is that the L2 address in 6lo link-layer
	technologies is a little short, and devices can become vulnerable to
	the various threats. For global usage, a unique IPv6 address must be
	derived using an assigned prefix and a unique interface ID. <xref target="RFC8065" format="default" sectionFormat="of" derivedContent="RFC8065"/> provides such guidelines. For
	MAC-derived IPv6 addresses, refer to <xref target="RFC8163" format="default" sectionFormat="of" derivedContent="RFC8163"/> for mapping examples. Broadcast and
	multicast support are dependent on the L2 networks. Most low-power L2
	implementations map multicast to broadcast networks. So care must be
	taken in the design for when to use broadcast, trying to stick to
	unicast messaging whenever possible.</dd>
        <dt pn="section-3-2.3">MTU Considerations:</dt>
        <dd pn="section-3-2.4">The deployment should consider packet maximum transmission unit
	(MTU) needs over the link layer and should consider if fragmentation
	and reassembly of packets are needed at the 6LoWPAN layer. For
	example, if the link layer supports fragmentation and reassembly of
	packets, then the 6LoWPAN layer may not need to support fragmentation
	and reassembly. In fact, for greatest efficiency, choosing a low-power
	link layer that can carry unfragmented application packets would be
	optimal for packet transmission if the deployment can afford
	it. Please refer to 6lo RFCs <xref target="RFC7668" format="default" sectionFormat="of" derivedContent="RFC7668"/>, <xref target="RFC8163" format="default" sectionFormat="of" derivedContent="RFC8163"/>, and
	<xref target="RFC8105" format="default" sectionFormat="of" derivedContent="RFC8105"/> for example guidance.</dd>
        <dt pn="section-3-2.5">Mesh or L3 Routing:</dt>
        <dd pn="section-3-2.6">6LoWPAN specifications provide mechanisms to support mesh routing
	at L2, a configuration called "mesh-under" <xref target="RFC6606" format="default" sectionFormat="of" derivedContent="RFC6606"/>. It is also possible to use an L3 routing protocol
	in 6LoWPAN, an approach known as "route-over". <xref target="RFC6550" format="default" sectionFormat="of" derivedContent="RFC6550"/> defines RPL, an L3 routing protocol for low-power and lossy networks
	using directed acyclic graphs. 6LoWPAN is routing-protocol-agnostic
	and does not specify any particular L2 or L3 routing protocol to use
	with a 6LoWPAN stack.</dd>
        <dt pn="section-3-2.7">Address Assignment:</dt>
        <dd pn="section-3-2.8">6LoWPAN developed a new version of IPv6 Neighbor Discovery <xref target="RFC4861" format="default" sectionFormat="of" derivedContent="RFC4861"/> <xref target="RFC4862" format="default" sectionFormat="of" derivedContent="RFC4862"/>. 6LoWPAN Neighbor Discovery <xref target="RFC6775" format="default" sectionFormat="of" derivedContent="RFC6775"/> <xref target="RFC8505" format="default" sectionFormat="of" derivedContent="RFC8505"/> inherits
	from IPv6 Neighbor Discovery for mechanisms such as Stateless Address
	Autoconfiguration (SLAAC) and Neighbor Unreachability Detection
	(NUD). A 6LoWPAN node is also expected to be an IPv6 host per <xref target="RFC8200" format="default" sectionFormat="of" derivedContent="RFC8200"/>, which means it should ignore
	consumed routing headers and hop-by-hop options. When operating in an
	RPL network <xref target="RFC6550" format="default" sectionFormat="of" derivedContent="RFC6550"/>, it is also
	beneficial to support IP-in-IP encapsulation <xref target="RFC9008" format="default" sectionFormat="of" derivedContent="RFC9008"/>. The 6LoWPAN node should
      also support the registration extensions defined in <xref target="RFC8505" format="default" sectionFormat="of" derivedContent="RFC8505"/> and use the mechanism as the default Neighbor Discovery method. It is the responsibility of
	the deployment to ensure unique global IPv6 addresses for Internet
	connectivity. For local-only connectivity, IPv6 Unique Local Address
	(ULA) may be used. <xref target="RFC6775" format="default" sectionFormat="of" derivedContent="RFC6775"/> and <xref target="RFC8505" format="default" sectionFormat="of" derivedContent="RFC8505"/> specify the 6LoWPAN Border Router
	(6LBR), which is responsible for prefix assignment to the 6LoWPAN
	network. A 6LBR can be connected to the Internet or to an enterprise
	network via one of the interfaces. Please refer to <xref target="RFC7668" format="default" sectionFormat="of" derivedContent="RFC7668"/> and <xref target="RFC8105" format="default" sectionFormat="of" derivedContent="RFC8105"/> for examples of address assignment
	considerations. In addition, privacy considerations in <xref target="RFC8065" format="default" sectionFormat="of" derivedContent="RFC8065"/> must be consulted for
	applicability. In certain scenarios, the deployment may not support
	IPv6 address autoconfiguration due to regulatory and business reasons
	and may choose to offer a separate address assignment service.
Address-Protected Neighbor Discovery
	<xref target="RFC8928" format="default" sectionFormat="of" derivedContent="RFC8928"/> enables source address
	validation <xref target="RFC6620" format="default" sectionFormat="of" derivedContent="RFC6620"/> and protects the
	address ownership against impersonation attacks.</dd>
        <dt pn="section-3-2.9">Broadcast Avoidance:</dt>
        <dd pn="section-3-2.10">6LoWPAN Neighbor Discovery aims to reduce the amount of
	multicast traffic of classic Neighbor Discovery, since IP-level
	multicast translates into L2 broadcast in many L2 technologies <xref target="RFC6775" format="default" sectionFormat="of" derivedContent="RFC6775"/>. 6LoWPAN Neighbor Discovery relies
	on a proactive registration to avoid the use of multicast for address
	resolution. It also uses a unicast method for Duplicate Address
	Detection (DAD) and avoids multicast lookups from all nodes by using
	non-onlink prefixes. Router Advertisements (RAs) are also sent in
	unicast, in response to Router Solicitations (RSs).</dd>
        <dt pn="section-3-2.11">Host-to-Router Interface:</dt>
        <dd pn="section-3-2.12">6lo has defined registration extensions for 6LoWPAN Neighbor
	Discovery <xref target="RFC8505" format="default" sectionFormat="of" derivedContent="RFC8505"/>. This effort
	provides a host-to-router interface by which a host can request its
	router to ensure reachability for the address registered with the
	router. Note that functionality has been developed to ensure that such
	a host can benefit from routing services in a RPL network <xref target="RFC9010" format="default" sectionFormat="of" derivedContent="RFC9010"/>.</dd>
        <dt pn="section-3-2.13">Proxy Neighbor Discovery:</dt>
        <dd pn="section-3-2.14">Further functionality also allows a device (e.g., an
	energy-constrained device that needs to sleep most of the time) to
	request proxy Neighbor Discovery services from a 6LoWPAN Backbone
	Router (6BBR) <xref target="RFC8505" format="default" sectionFormat="of" derivedContent="RFC8505"/> <xref target="RFC8929" format="default" sectionFormat="of" derivedContent="RFC8929"/>. The latter RFC federates a number
	of links into a multi-link subnet. </dd>
        <dt pn="section-3-2.15">Header Compression:</dt>
        <dd pn="section-3-2.16">IPv6 header compression <xref target="RFC6282" format="default" sectionFormat="of" derivedContent="RFC6282"/>
	is a vital part of IPv6 over low-power communication. Examples of
	header compression over different link-layer specifications are found
	in <xref target="RFC7668" format="default" sectionFormat="of" derivedContent="RFC7668"/>, <xref target="RFC8163" format="default" sectionFormat="of" derivedContent="RFC8163"/>, and <xref target="RFC8105" format="default" sectionFormat="of" derivedContent="RFC8105"/>. A
	generic header compression technique is specified in <xref target="RFC7400" format="default" sectionFormat="of" derivedContent="RFC7400"/>. 


For 6LoWPAN networks where RPL is
	the routing protocol, there are 6LoWPAN header compression extensions
	that allow compressing the RPL artifacts used when forwarding packets
	in the route-over mesh <xref target="RFC8138" format="default" sectionFormat="of" derivedContent="RFC8138"/> <xref target="RFC9035" format="default" sectionFormat="of" derivedContent="RFC9035"/>.</dd>
        <dt pn="section-3-2.17">Security and Encryption:</dt>
        <dd pn="section-3-2.18">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" format="default" sectionFormat="of" derivedContent="Section 2"/>) offer security properties such as
	confidentiality and/or message authentication. In addition, end-to-end
	security is highly desirable. Protocols such as DTLS/TLS, as well as
	Object Security, are being used in the constrained-node network domain
	<xref target="I-D.ietf-iotops-security-protocol-comparison" format="default" sectionFormat="of" derivedContent="SEC-PROT-COMP"/>. 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" sectionFormat="of" derivedContent="RFC8928"/>, and secure bootstrapping is also being discussed in
	the IETF. However, there may be other security mechanisms available in
	a deployment through other standards, such as hardware-level security
	or certificates for the initial booting process. In order to use
	security mechanisms, the implementation needs to be able to afford it in terms of
	processing capabilities and energy consumption.</dd>
        <dt pn="section-3-2.19">Additional Processing:</dt>
        <dd pn="section-3-2.20">
          <xref target="RFC8066" format="default" sectionFormat="of" derivedContent="RFC8066"/> defines guidelines for
	ESC dispatch octets used in the 6LoWPAN header. The ESC type is defined
	to use additional dispatch octets in the 6LoWPAN header. An
	implementation may take advantage of the ESC header to offer a
	deployment-specific processing of 6LoWPAN packets.</dd>
      </dl>
    </section>
    <section numbered="true" toc="include" removeInRFC="false" pn="section-4">
      <name slugifiedName="name-6lo-deployment-examples">6lo Deployment Examples</name>
      <section numbered="true" toc="include" removeInRFC="false" pn="section-4.1">
        <name slugifiedName="name-wi-sun-usage-of-6lo-in-netw">Wi-SUN Usage of 6lo in Network Layer</name>
        <t indent="0" pn="section-4.1-1">Wireless Smart Ubiquitous Network (Wi-SUN) <xref target="Wi-SUN" format="default" sectionFormat="of" derivedContent="Wi-SUN"/> is a technology based on IEEE Std 802.15.4g <xref target="IEEE-802.15.4" format="default" sectionFormat="of" derivedContent="IEEE-802.15.4"/>. Wi-SUN
        networks support star and mesh topologies as well as hybrid star/mesh
        deployments, but these are typically laid out in a mesh topology where
        each node relays data for the network to provide network
        connectivity. Wi-SUN networks are deployed on both grid-powered and
        battery-operated devices <xref target="RFC8376" format="default" sectionFormat="of" derivedContent="RFC8376"/>.</t>
        <t indent="0" pn="section-4.1-2"> The main application domains using Wi-SUN are smart utility and
        smart city networks. The Wi-SUN Alliance Field Area Network (FAN)
        primarily covers outdoor networks. The Wi-SUN FAN specification
        defines an IPv6-based protocol suite that includes TCP/UDP, IPv6, 6lo
        adaptation layer, DHCPv6 for IPv6 address management, RPL, and
        ICMPv6. </t>
      </section>
      <section numbered="true" toc="include" removeInRFC="false" pn="section-4.2">
        <name slugifiedName="name-thread-usage-of-6lo-in-the-">Thread Usage of 6lo in the Network Layer</name>
        <t indent="0" pn="section-4.2-1">Thread is an IPv6-based networking protocol stack built on open
        standards, designed for smart home environments, and based on
        low-power IEEE Std 802.15.4 mesh networks. Because of its IPv6
        foundation, Thread can support existing popular application layers and
        IoT platforms, provide end-to-end security, ease development, and
        enable flexible designs <xref target="Thread" format="default" sectionFormat="of" derivedContent="Thread"/>.</t>
        <t indent="0" pn="section-4.2-2">The Thread specification uses the IEEE Std 802.15.4 <xref target="IEEE-802.15.4" format="default" sectionFormat="of" derivedContent="IEEE-802.15.4"/> physical and MAC layers operating at 250 kbps in the 2.4 GHz band.</t>
        <t indent="0" pn="section-4.2-3">Thread devices use 6LoWPAN, as defined in <xref target="RFC4944" format="default" sectionFormat="of" derivedContent="RFC4944"/> and <xref target="RFC6282" format="default" sectionFormat="of" derivedContent="RFC6282"/>, for transmission of IPv6 packets over IEEE Std 802.15.4 networks. Header compression is used within the Thread network, and devices transmitting messages compress the IPv6 header to minimize the size of the transmitted packet. The mesh header is supported for link-layer (i.e., mesh-under) forwarding. The mesh header as used in Thread also allows efficient end-to-end fragmentation of messages rather than the hop-by-hop fragmentation specified in <xref target="RFC4944" format="default" sectionFormat="of" derivedContent="RFC4944"/>. Mesh-under routing in Thread is based on a distance vector protocol in a full mesh topology.</t>
      </section>
      <section numbered="true" toc="include" removeInRFC="false" pn="section-4.3">
        <name slugifiedName="name-g3-plc-usage-of-6lo-in-netw">G3-PLC Usage of 6lo in Network Layer</name>
        <t indent="0" pn="section-4.3-1">G3-PLC <xref target="G3-PLC" format="default" sectionFormat="of" derivedContent="G3-PLC"/> is a narrowband PLC
        technology that is based on the ITU-T G.9903 Recommendation <xref target="G.9903" format="default" sectionFormat="of" derivedContent="G.9903"/>. G3-PLC supports multi-hop mesh
        network topology and facilitates highly reliable, long-range
        communication. With the abilities to support IPv6 and to cross
        transformers, G3-PLC is regarded as one of the next-generation
        narrowband PLC technologies. G3-PLC has got massive deployments over
        several countries, e.g., Japan and France. </t>
        <t indent="0" pn="section-4.3-2"> 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" bare="false" empty="false" indent="3" pn="section-4.3-3">
          <li pn="section-4.3-3.1">smart metering</li>
          <li pn="section-4.3-3.2">vehicle-to-grid communication</li>
          <li pn="section-4.3-3.3">demand response</li>
          <li pn="section-4.3-3.4">distribution automation</li>
          <li pn="section-4.3-3.5">home/building energy management systems</li>
          <li pn="section-4.3-3.6">smart street lighting</li>
          <li pn="section-4.3-3.7">AMI backbone network</li>
          <li pn="section-4.3-3.8">wind/solar farm monitoring</li>
        </ul>
        <t indent="0" pn="section-4.3-4">In the G3-PLC specification, the 6lo adaption layer utilizes the 6LoWPAN functions (e.g., header compression, fragmentation, and
reassembly). However, due to the different characteristics of the PLC media, the 6LoWPAN adaptation layer cannot perfectly fulfill the requirements <xref target="RFC9354" format="default" sectionFormat="of" derivedContent="RFC9354"/>. The ESC dispatch type is used in the G3-PLC to provide fundamental mesh routing and bootstrapping functionalities <xref target="RFC8066" format="default" sectionFormat="of" derivedContent="RFC8066"/>.</t>
      </section>
      <section numbered="true" toc="include" removeInRFC="false" pn="section-4.4">
        <name slugifiedName="name-netricity-usage-of-6lo-in-t">Netricity Usage of 6lo in the Network Layer</name>
        <t indent="0" pn="section-4.4-1">The Netricity program in the HomePlug Powerline Alliance <xref target="NETRICITY" format="default" sectionFormat="of" derivedContent="NETRICITY"/> promotes the adoption of products built on the IEEE Std 1901.2 low-frequency narrowband PLC standard <xref target="IEEE-1901.2" format="default" sectionFormat="of" derivedContent="IEEE-1901.2"/>, which provides for urban and long-distance communications and propagation through transformers of the distribution network using frequencies below 500 kHz. The technology also addresses requirements that assure communication privacy and secure networks. </t>
        <t indent="0" pn="section-4.4-2"> The main application domains using Netricity are smart grid and smart cities. This includes, but is not limited to, the following applications:</t>
        <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-4.4-3">
          <li pn="section-4.4-3.1">utility grid modernization</li>
          <li pn="section-4.4-3.2">distribution automation</li>
          <li pn="section-4.4-3.3">meter-to-grid connectivity</li>
          <li pn="section-4.4-3.4">microgrids</li>
          <li pn="section-4.4-3.5">grid sensor communications</li>
          <li pn="section-4.4-3.6">load control</li>
          <li pn="section-4.4-3.7">demand response</li>
          <li pn="section-4.4-3.8">net metering</li>
          <li pn="section-4.4-3.9">street lighting control</li>
          <li pn="section-4.4-3.10">photovoltaic panel monitoring</li>
        </ul>
        <t indent="0" pn="section-4.4-4">The Netricity system architecture is based on the physical and MAC layers of IEEE Std 1901.2. Regarding the 6lo adaptation layer and an IPv6 network layer, Netricity utilizes IPv6 protocol suite including 6lo/6LoWPAN header compression, DHCPv6 for IP address management, RPL routing protocol, ICMPv6, and unicast/multicast forwarding. Note that the L3 routing in Netricity uses RPL in non-storing mode with the MRHOF (Minimum Rank with Hysteresis Objective Function) based on their own defined Estimated Transmission Time (ETT) metric.</t>
      </section>
    </section>
    <section numbered="true" toc="include" removeInRFC="false" pn="section-5">
      <name slugifiedName="name-6lo-use-case-examples">6lo Use-Case Examples</name>
      <t indent="0" pn="section-5-1">As IPv6 stacks for constrained-node networks use a variation of the 6LoWPAN stack applied to each particular link-layer technology, various 6lo use cases can be provided. In this section, various 6lo use cases, which are based on different link-layer technologies, are described.</t>
      <section numbered="true" toc="include" removeInRFC="false" pn="section-5.1">
        <name slugifiedName="name-use-case-of-itu-t-g9959-sma">Use Case of ITU-T G.9959: Smart Home</name>
        <t indent="0" pn="section-5.1-1"> Z-Wave is one of the main technologies that may be used to enable smart home applications. Born as a proprietary technology, Z-Wave was specifically designed for this particular use case. Recently, the Z-Wave radio interface (physical and MAC layers) has been standardized as the ITU-T G.9959 specification <xref target="G.9959" format="default" sectionFormat="of" derivedContent="G.9959"/>. </t>
        <t indent="0" pn="section-5.1-2">Example: Use of ITU-T G.9959 for Home Automation</t>
        <t indent="3" pn="section-5.1-3">A variety of home devices (e.g., light dimmers/switches, plugs,
          thermostats, blinds/curtains, and remote controls) are augmented
          with ITU-T G.9959 interfaces. 
   A user may turn home appliances on and off, or the user may control them
   by pressing a wall switch or a button on a
   remote control.
Scenes may be programmed so that
          the home devices adopt a specific configuration after a given event. Sensors may
          also periodically send measurements of several parameters (e.g., gas
          presence, light, temperature, humidity), which are collected at a
          sink device, or may generate commands for actuators (e.g., a smoke
          sensor may send an alarm message to a safety system).</t>
        <t indent="0" pn="section-5.1-4">The devices involved in the described scenario are nodes of a network that follows the mesh topology, which is suitable for path diversity to face indoor multipath propagation issues. The multi-hop paradigm allows end-to-end connectivity when direct range communication is not possible.</t>
      </section>
      <section numbered="true" toc="include" removeInRFC="false" pn="section-5.2">
        <name slugifiedName="name-use-case-of-bluetooth-le-sm">Use Case of Bluetooth LE: Smartphone-Based Interaction</name>
        <t indent="0" pn="section-5.2-1">The key feature behind the current high Bluetooth LE momentum is its support in a large majority of smartphones in the market. Bluetooth LE can be used to allow interaction between a smartphone and surrounding sensors or actuators. Furthermore, Bluetooth LE is also the main radio interface currently available in wearables. Since a smartphone typically has several radio interfaces that provide Internet access, such as Wi-Fi or cellular, a smartphone can act as a gateway for nearby devices, such as sensors, actuators, or wearables. Bluetooth LE may be used in several domains, including healthcare, sports/wellness, and home automation. </t>
        <t indent="0" pn="section-5.2-2">Example: Use of a Body Area Network Based on Bluetooth LE for Fitness</t>
        <t indent="3" pn="section-5.2-3">A person wears a smartwatch for fitness purposes. The smartwatch
        has several sensors (e.g., heart rate, accelerometer, gyrometer, GPS,
        and temperature), a display, and a Bluetooth LE radio interface. The
        smartwatch can show fitness-related statistics on its
        display. However, when a paired smartphone is in range of the
        smartwatch, the latter can report almost real-time measurements of its
        sensors to the smartphone, which can forward the data to a cloud
        service on the Internet. 6lo enables this use case by providing
        efficient end-to-end IPv6 support. In addition, the smartwatch can
        receive notifications (e.g., alarm signals) from the cloud service via
        the smartphone. On the other hand, the smartphone may locally generate
        messages for the smartwatch, such as e-mail reception or calendar
        notifications.</t>
        <t indent="0" pn="section-5.2-4"> The functionality supported by the smartwatch may be complemented by other devices, such as other on-body sensors, wireless headsets, or head-mounted displays. All such devices may connect to the smartphone, creating a star topology network whereby the smartphone is the central component. Support for extended network topologies (e.g., mesh networks) is being developed as of the writing of this document.</t>
      </section>
      <section numbered="true" toc="include" removeInRFC="false" pn="section-5.3">
        <name slugifiedName="name-use-case-of-dect-ule-smart-">Use Case of DECT-ULE: Smart Home</name>
        <t indent="0" pn="section-5.3-1">DECT is a technology widely used for wireless telephone
        communications in residential scenarios. Since DECT-ULE is a low-power
        variant of DECT, DECT-ULE can be used to connect constrained devices
        (such as sensors and actuators) to a Fixed Part (FP), a device that
        typically acts as a base station for wireless telephones. In this
        case, additionally, the FP must have a data network
        connection. Therefore, DECT-ULE is especially suitable for the
        connected home space in application areas such as home automation,
        smart metering, safety, and healthcare. Since DECT-ULE uses dedicated
        bandwidth, it avoids this coexistence issues suffered by other
        technologies that use, for example, Industrial, Scientific, and Medical (ISM) frequency bands.</t>
        <t indent="0" pn="section-5.3-2">Example: Use of DECT-ULE for Smart Metering</t>
        <t indent="3" pn="section-5.3-3">The smart electricity meter of a home is equipped with a DECT-ULE
        transceiver. This device is in the coverage range of the FP of
        the home. The FP can act as a router connected to the
        Internet. This way, the smart meter can transmit electricity
        consumption readings through the DECT-ULE link with the FP,
        and the latter can forward such readings to the utility company using
        Wide Area Network (WAN) links. The meter can also receive queries from
        the utility company or from an advanced energy control system
        controlled by the user, which may also be connected to the FP
        via DECT-ULE.</t>
      </section>
      <section numbered="true" toc="include" removeInRFC="false" pn="section-5.4">
        <name slugifiedName="name-use-case-of-ms-tp-building-">Use Case of MS/TP: Building Automation Networks</name>
        <t indent="0" pn="section-5.4-1"> The primary use case for IPv6 over MS/TP (6LoBAC) is in building automation networks. <xref target="BACnet" format="default" sectionFormat="of" derivedContent="BACnet"/> is the open, international standard  protocol for building automation, and MS/TP is defined in <xref target="BACnet" format="default" sectionFormat="of" derivedContent="BACnet"/> Clause 9.  MS/TP was designed to be a low-cost, multi-drop field bus to interconnect the most numerous elements (sensors and actuators) of a building automation network to their controllers.  A key aspect of 6LoBAC is that it is designed to co-exist with BACnet MS/TP on the same link, easing the ultimate transition of some BACnet networks to fundamental end-to-end IPv6 transport protocols. New applications for 6LoBAC may be found in other domains where low cost, long distance, and low latency are required. Note that BACnet comprises various networking solutions other than MS/TP, including the recently emerged BACnet IP. However, the latter is based on high-speed Ethernet infrastructure, and it is outside of the constrained-node network scope.</t>
        <t indent="0" pn="section-5.4-2">Example: Use of 6LoBAC in Building Automation Networks</t>
        <t indent="3" pn="section-5.4-3">The majority of installations for MS/TP are for "terminal" or
        "unitary" controllers, i.e., single zone or room controllers that may
        connect to HVAC or other controls such as lighting or blinds. The
        economics of daisy chaining a single twisted pair between multiple
        devices is often preferred over home-run, Cat-5-style wiring.</t>
        <t indent="0" pn="section-5.4-4"> A multi-zone controller might be implemented as an IP router between a classical Ethernet link and several 6LoBAC links, fanning out to multiple terminal controllers.</t>
        <t indent="0" pn="section-5.4-5">The superior distance capabilities of MS/TP (~1 km) compared to other 6lo media may suggest its use in applications to connect remote devices to the nearest building infrastructure. For example, remote pumping or measuring stations with moderate bandwidth requirements can benefit from the low-cost and robust capabilities of MS/TP over other wired technologies such as DSL, without the line-of-sight restrictions or hop-by-hop latency of many low-cost wireless solutions.</t>
      </section>
      <section numbered="true" toc="include" removeInRFC="false" pn="section-5.5">
        <name slugifiedName="name-use-case-of-nfc-alternative">Use Case of NFC: Alternative Secure Transfer</name>
        <t indent="0" pn="section-5.5-1">In different applications, a variety of secured data can be handled and transferred. Depending on the security level of the data, different transfer methods can be alternatively selected.</t>
        <t indent="0" pn="section-5.5-2">Example: Use of NFC for Secure Transfer in Healthcare Services with
	Tele-Assistance </t>
        <t indent="3" pn="section-5.5-3">An older adult who lives alone wears one to several wearable
        6lo devices to measure heartbeat, pulse rate, etc. Other 6lo devices
        are densely installed at home for movement detection. A 6LBR at home
        will send the sensed information to a connected healthcare
        center. Portable base stations with displays may be used to check the
        data at home, as well. Data is gathered in both periodic and
        event-driven fashion. In this application, event-driven data can be
        very time critical. In addition, privacy becomes a serious issue
        in this case, as the sensed data is very personal.</t>
        <t indent="0" pn="section-5.5-4">While the older adult is provided audio and video healthcare services by a tele-assistance based on cellular connections, the older adult can alternatively use NFC connections to transfer the personal sensed data to the tele-assistance. Hackers can overhear the data based on the cellular connection, but they cannot gather the personal data over the NFC connection.</t>
      </section>
      <section numbered="true" toc="include" removeInRFC="false" pn="section-5.6">
        <name slugifiedName="name-use-case-of-plc-smart-grid">Use Case of PLC: Smart Grid</name>
        <t indent="0" pn="section-5.6-1">The smart grid concept is based on deploying numerous operational and energy measuring subsystems in an electricity grid system. It comprises multiple administrative levels and segments to provide connectivity among these numerous components.  Last mile connectivity is established over the Low-Voltage segment, whereas connectivity over electricity distribution takes place over the High-Voltage segment. Smart grid systems include AMI, Demand Response, Home Energy Management System, and Wide Area Situational Awareness (WASA), among others.</t>
        <t indent="0" pn="section-5.6-2">
   Although other wired and wireless technologies are also used in a
   smart grid, PLC benefits from reliable data 
   communication over electrical power lines that are already present, 
   and the deployment cost can be comparable to wireless technologies. 
The 6lo-related scenarios for PLC mainly lie in the Low-Voltage PLC networks with most applications in the area of advanced metering infrastructure, vehicle-to-grid communications, in-home energy management, and smart street lighting.</t>
        <t indent="0" pn="section-5.6-3">Example: Use of PLC for AMI</t>
        <t indent="3" pn="section-5.6-4">Household electricity meters transmit time-based data of electric
        power consumption through PLC. Data concentrators receive all the
        meter data in their corresponding living districts and send them to
        the Meter Data Management System through a WAN network (e.g.,
        Medium-Voltage PLC, Ethernet, or General Packet Radio Service (GPRS)) for storage and analysis.
        Two-way communications are enabled, which means smart meters can
        perform actions like notification of electricity charges according to
        the commands from the utility company.</t>
        <t indent="0" pn="section-5.6-5">With the existing power line infrastructure as a communication
        medium, the cost of building up the PLC network is naturally saved, and
        more importantly, labor and operational costs can be minimized from a
        long-term perspective. Furthermore, this AMI application speeds up
        electricity charging, reduces losses by restraining power theft, and
        helps to manage the health of the grid based on line loss
        analysis.</t>
        <t indent="0" pn="section-5.6-6">Example: Use of PLC (IEEE Std 1901.1) for WASA in a Smart Grid</t>
        <t indent="3" pn="section-5.6-7">Many subsystems of a smart grid require low data rates, and
        narrowband variants (e.g., IEEE Std 1901.1) of PLC fulfill such
        requirements.  Recently, more complex scenarios are emerging that
        require higher data rates.</t>
        <t indent="0" pn="section-5.6-8">A WASA subsystem is an appropriate example that collects large
        amounts of information about the current state of the grid over a wide
        area from electric substations as well as power transmission
        lines. The collected feedback is used for monitoring, controlling, and
        protecting all the subsystems.</t>
      </section>
    </section>
    <section anchor="IANA" numbered="true" toc="include" removeInRFC="false" pn="section-6">
      <name slugifiedName="name-iana-considerations">IANA Considerations</name>
      <t indent="0" pn="section-6-1">This document has no IANA actions.</t>
    </section>
    <section numbered="true" toc="include" removeInRFC="false" pn="section-7">
      <name slugifiedName="name-security-considerations">Security Considerations</name>
      <t indent="0" pn="section-7-1">   This document does not create security concerns in addition to those described in the Security Considerations sections of the 6lo adaptation layers considered in this document <xref target="RFC7428" format="default" sectionFormat="of" derivedContent="RFC7428"/>, <xref target="RFC7668" format="default" sectionFormat="of" derivedContent="RFC7668"/>, <xref target="RFC8105" format="default" sectionFormat="of" derivedContent="RFC8105"/>, <xref target="RFC8163" format="default" sectionFormat="of" derivedContent="RFC8163"/>, <xref target="RFC9159" format="default" sectionFormat="of" derivedContent="RFC9159"/>, <xref target="RFC9428" format="default" sectionFormat="of" derivedContent="RFC9428"/>, and <xref target="RFC9354" format="default" sectionFormat="of" derivedContent="RFC9354"/>.</t>
      <t indent="0" pn="section-7-2">Neighbor Discovery in 6lo links may be susceptible to threats as detailed in <xref target="RFC3756" format="default" sectionFormat="of" derivedContent="RFC3756"/>. Mesh routing is expected to be common in some 6lo networks, such as ITU-T G.9959 networks, Bluetooth LE mesh networks, and PLC networks. This implies additional threats due to ad hoc routing as per <xref target="KW03" format="default" sectionFormat="of" derivedContent="KW03"/>. Most of the L2 technologies considered in this document (i.e., ITU-T G.9959, Bluetooth LE, DECT-ULE, and PLC) support link-layer security. Making use of such provisions will alleviate the threats mentioned above. Note that NFC is often considered to offer intrinsic security properties due to its short link range. MS/TP does not support link-layer security, since in its original BACnet protocol stack, security is provided at the network layer; thus, alternative security functionality needs to be used for a 6lo-based protocol stack over MS/TP.</t>
      <t indent="0" pn="section-7-3">End-to-end communication is expected to be secured by means of common mechanisms, such as IPsec, DTLS/TLS, Object Security <xref target="RFC8613" format="default" sectionFormat="of" derivedContent="RFC8613"/>, and Ephemeral Diffie-Hellman Over COSE (EDHOC) <xref target="I-D.ietf-lake-edhoc" format="default" sectionFormat="of" derivedContent="EDHOC"/>.</t>
      <t indent="0" pn="section-7-4">The 6lo stack uses the IPv6 addressing model. The implications for privacy and network performance of using L2-address-derived IPv6 addresses need to be considered <xref target="RFC8065" format="default" sectionFormat="of" derivedContent="RFC8065"/>.</t>
    </section>
  </middle>
  <back>
    <displayreference target="I-D.ietf-iotops-security-protocol-comparison" to="SEC-PROT-COMP"/>
    <displayreference target="I-D.ietf-lake-edhoc" to="EDHOC"/>
    <references pn="section-8">
      <name slugifiedName="name-references">References</name>
      <references pn="section-8.1">
        <name slugifiedName="name-normative-references">Normative References</name>
        <reference anchor="RFC4861" target="https://www.rfc-editor.org/info/rfc4861" quoteTitle="true" derivedAnchor="RFC4861">
          <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 indent="0">This document specifies the Neighbor Discovery protocol for IP Version 6. IPv6 nodes on the same link use Neighbor Discovery to discover each other'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/rfc4862" quoteTitle="true" derivedAnchor="RFC4862">
          <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 indent="0">This document specifies the steps a host takes in deciding how to autoconfigure its interfaces in IP version 6. The autoconfiguration process includes generating a link-local address, generating global addresses via stateless address autoconfiguration, and the Duplicate Address Detection procedure to verify 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/rfc4919" quoteTitle="true" derivedAnchor="RFC4919">
          <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 indent="0">This document describes the assumptions, problem statement, and goals for transmitting IP over IEEE 802.15.4 networks. The set of goals enumerated in this document form an initial set only. This memo provides information for 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/rfc4944" quoteTitle="true" derivedAnchor="RFC4944">
          <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 indent="0">This document describes the frame format for transmission of IPv6 packets and the method of forming IPv6 link-local addresses and statelessly autoconfigured addresses on IEEE 802.15.4 networks. Additional specifications include a simple header compression scheme using shared context and provisions for packet 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" quoteTitle="true" derivedAnchor="RFC6568">
          <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 indent="0">This document investigates potential application scenarios and use cases for low-power wireless personal area networks (LoWPANs). This document provides dimensions of design space for LoWPAN applications. A list of use cases and market domains that may benefit and motivate the work currently done in the 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 informational 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/rfc6606" quoteTitle="true" derivedAnchor="RFC6606">
          <front>
            <title>Problem Statement and Requirements for IPv6 over Low-Power Wireless 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 indent="0">IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs) are 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 defines how mesh topologies could be obtained and maintained. Thus, it should be considered how 6LoWPAN formation and multi-hop routing could be supported.</t>
              <t indent="0">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 ROLL WG. This document is not an Internet Standards Track specification; it is published 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/rfc7228" quoteTitle="true" derivedAnchor="RFC7228">
          <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 indent="0">The Internet Protocol Suite is increasingly used on small devices with severe constraints on power, memory, and processing resources, creating constrained-node networks. This document provides a number of basic terms that have 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/rfc7400" quoteTitle="true" derivedAnchor="RFC7400">
          <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 indent="0">RFC 6282 defines header compression in 6LoWPAN packets (where "6LoWPAN" refers to "IPv6 over Low-Power Wireless Personal Area Network"). The present document specifies a simple addition that enables the compression of generic headers and header-like payloads, without a need to define a new header compression 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/rfc7428" quoteTitle="true" derivedAnchor="RFC7428">
          <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 indent="0">This document describes the frame format for transmission of IPv6 packets as well as a method of forming IPv6 link-local addresses and statelessly 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/rfc7668" quoteTitle="true" derivedAnchor="RFC7668">
          <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 indent="0">Bluetooth Smart is the brand name for the Bluetooth low energy feature in the Bluetooth specification defined by the Bluetooth Special Interest Group. 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 Bluetooth specifications, although version 4.1 or newer is required for IPv6. This document describes how IPv6 is transported over Bluetooth low energy using IPv6 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/rfc8105" quoteTitle="true" derivedAnchor="RFC8105">
          <front>
            <title>Transmission of IPv6 Packets over Digital Enhanced Cordless Telecommunications (DECT) Ultra Low Energy (ULE)</title>
            <author fullname="P. Mariager" initials="P." surname="Mariager"/>
            <author fullname="J. Petersen" initials="J." role="editor" surname="Petersen"/>
            <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 indent="0">Digital Enhanced Cordless Telecommunications (DECT) Ultra Low Energy (ULE) is a low-power air interface technology that is proposed by the DECT Forum and is defined and specified by ETSI.</t>
              <t indent="0">The DECT air interface technology has been used worldwide in communication devices for more than 20 years. It has primarily been used to carry voice for cordless telephony but has also been deployed for data-centric services.</t>
              <t indent="0">DECT ULE is a recent addition to the DECT interface primarily intended for low-bandwidth, low-power applications such as sensor devices, smart meters, home automation, etc. As the DECT ULE interface inherits many of the capabilities from DECT, it benefits from operation that is long-range and interference-free, worldwide- reserved frequency band, low silicon prices, and maturity. There is an added value in the ability to communicate with IPv6 over DECT ULE, such as for Internet of Things applications.</t>
              <t indent="0">This document describes how IPv6 is transported over DECT ULE using 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/rfc8163" quoteTitle="true" derivedAnchor="RFC8163">
          <front>
            <title>Transmission of IPv6 over Master-Slave/Token-Passing (MS/TP) Networks</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 indent="0">Master-Slave/Token-Passing (MS/TP) is a medium access control method for the RS-485 physical layer and is used primarily in building automation networks. This specification defines the frame format for transmission of IPv6 packets 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/rfc8200" quoteTitle="true" derivedAnchor="RFC8200">
          <front>
            <title>Internet Protocol, Version 6 (IPv6) Specification</title>
            <author fullname="S. Deering" initials="S." surname="Deering"/>
            <author fullname="R. Hinden" initials="R." surname="Hinden"/>
            <date month="July" year="2017"/>
            <abstract>
              <t indent="0">This document specifies version 6 of the Internet Protocol (IPv6). It obsoletes RFC 2460.</t>
            </abstract>
          </front>
          <seriesInfo name="STD" value="86"/>
          <seriesInfo name="RFC" value="8200"/>
          <seriesInfo name="DOI" value="10.17487/RFC8200"/>
        </reference>
        <reference anchor="RFC9159" target="https://www.rfc-editor.org/info/rfc9159" quoteTitle="true" derivedAnchor="RFC9159">
          <front>
            <title>IPv6 Mesh over BLUETOOTH(R) Low Energy Using the Internet Protocol Support Profile (IPSP)</title>
            <author fullname="C. Gomez" initials="C." surname="Gomez"/>
            <author fullname="S.M. Darroudi" initials="S.M." surname="Darroudi"/>
            <author fullname="T. Savolainen" initials="T." surname="Savolainen"/>
            <author fullname="M. Spoerk" initials="M." surname="Spoerk"/>
            <date month="December" year="2021"/>
            <abstract>
              <t indent="0">RFC 7668 describes the adaptation of IPv6 over Low-Power Wireless Personal Area Network (6LoWPAN) techniques to enable IPv6 over Bluetooth Low Energy (Bluetooth LE) networks that follow the star topology. However, recent Bluetooth specifications allow the formation of extended topologies as well. This 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 IPv6 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/rfc9354" quoteTitle="true" derivedAnchor="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 pn="section-8.2">
        <name slugifiedName="name-informative-references">Informative References</name>
        <reference anchor="BACnet" target="https://www.techstreet.com/standards/ashrae-135-2020?product_id=2191852" quoteTitle="true" derivedAnchor="BACnet">
          <front>
            <title>BACnet-A Data Communication Protocol for Building Automation and Control Networks (ANSI Approved)</title>
            <author>
              <organization showOnFrontPage="true">ASHRAE</organization>
            </author>
            <date month="October" year="2020"/>
          </front>
          <seriesInfo name="ASHRAE Standard" value="135-2020"/>
        </reference>
        <reference anchor="BTCorev5.4" target="https://www.bluetooth.com/specifications/specs/core-specification-5-4/" quoteTitle="true" derivedAnchor="BTCorev5.4">
          <front>
            <title>Core Specification Version 5.4</title>
            <author>
              <organization showOnFrontPage="true">Bluetooth</organization>
            </author>
            <date year="2012" month="January"/>
          </front>
        </reference>
        <reference anchor="I-D.ietf-lake-edhoc" target="https://datatracker.ietf.org/doc/html/draft-ietf-lake-edhoc-22" quoteTitle="true" derivedAnchor="EDHOC">
          <front>
            <title>Ephemeral Diffie-Hellman Over COSE (EDHOC)</title>
            <author initials="G." surname="Selander" fullname="Göran Selander">
              <organization showOnFrontPage="true">Ericsson AB</organization>
            </author>
            <author initials="J." surname="Preuß Mattsson" fullname="John Preuß Mattsson">
              <organization showOnFrontPage="true">Ericsson AB</organization>
            </author>
            <author initials="F." surname="Palombini" fullname="Francesca Palombini">
              <organization showOnFrontPage="true">Ericsson AB</organization>
            </author>
            <date month="August" day="25" year="2023"/>
          </front>
          <seriesInfo name="Internet-Draft" value="draft-ietf-lake-edhoc-22"/>
          <refcontent>Work in Progress</refcontent>
        </reference>
        <reference anchor="G.9903" target="https://www.itu.int/rec/T-REC-G.9903-201708-I/en" quoteTitle="true" derivedAnchor="G.9903">
          <front>
            <title>Narrowband orthogonal frequency division multiplexing power line communication transceivers for G3-PLC networks</title>
            <author>
              <organization showOnFrontPage="true">ITU-T</organization>
            </author>
            <date month="August" year="2017"/>
          </front>
          <seriesInfo name="ITU-T Recommendation" value="G.9903"/>
        </reference>
        <reference anchor="G.9959" target="https://www.itu.int/rec/T-REC-G.9959-201501-I/en" quoteTitle="true" derivedAnchor="G.9959">
          <front>
            <title>Short range narrow-band digital radiocommunication transceivers - PHY, MAC, SAR and LLC layer specifications</title>
            <author>
              <organization showOnFrontPage="true">ITU-T</organization>
            </author>
            <date month="January" year="2015"/>
          </front>
          <seriesInfo name="ITU-T Recommendation" value="G.9959"/>
        </reference>
        <reference anchor="G3-PLC" target="https://g3-plc.com" quoteTitle="true" derivedAnchor="G3-PLC">
          <front>
            <title>G3-Alliance</title>
            <author/>
          </front>
        </reference>
        <reference anchor="IEEE-1901" target="https://standards.ieee.org/ieee/1901/4953/" quoteTitle="true" derivedAnchor="IEEE-1901">
          <front>
            <title>IEEE Standard for Broadband over Power Line Networks: Medium Access Control and Physical Layer Specifications</title>
            <author>
              <organization showOnFrontPage="true">IEEE</organization>
            </author>
            <date month="December" year="2010"/>
          </front>
          <seriesInfo name="DOI" value="10.1109/IEEESTD.2010.5678772"/>
          <seriesInfo name="IEEE Std" value="1901-2010"/>
        </reference>
        <reference anchor="IEEE-1901.1" target="https://ieeexplore.ieee.org/document/8360785" quoteTitle="true" derivedAnchor="IEEE-1901.1">
          <front>
            <title>IEEE Standard for Medium Frequency (less than 12 MHz) Power Line Communications for Smart Grid Applications</title>
            <author>
              <organization showOnFrontPage="true">IEEE</organization>
            </author>
            <date month="May" year="2018"/>
          </front>
          <seriesInfo name="DOI" value="10.1109/IEEESTD.2018.8360785"/>
          <seriesInfo name="IEEE Std" value="1901.1-2018"/>
        </reference>
        <reference anchor="IEEE-1901.2" target="https://standards.ieee.org/ieee/1901.2/4833/" quoteTitle="true" derivedAnchor="IEEE-1901.2">
          <front>
            <title>IEEE Standard for Low-Frequency (less than 500 kHz) Narrowband Power Line Communications for Smart Grid Applications</title>
            <author>
              <organization showOnFrontPage="true">IEEE</organization>
            </author>
            <date month="December" year="2013"/>
          </front>
          <seriesInfo name="DOI" value="10.1109/IEEESTD.2013.6679210"/>
          <seriesInfo name="IEEE Std" value="1901.2-2013"/>
        </reference>
        <reference anchor="IEEE-802.15.4" target="https://standards.ieee.org/ieee/802.15.4/7029/" quoteTitle="true" derivedAnchor="IEEE-802.15.4">
          <front>
            <title>IEEE Standard for Low-Rate Wireless Networks</title>
            <author>
              <organization showOnFrontPage="true">IEEE</organization>
            </author>
            <date month="July" year="2020"/>
          </front>
          <seriesInfo name="DOI" value="10.1109/IEEESTD.2020.9144691"/>
          <seriesInfo name="IEEE Std" value="802.15.4-2020"/>
        </reference>
        <reference anchor="IEEE-802.15.9" target="https://ieeexplore.ieee.org/document/9690134" quoteTitle="true" derivedAnchor="IEEE-802.15.9">
          <front>
            <title>IEEE Standard for Transport of Key Management Protocol (KMP) Datagrams</title>
            <author>
              <organization showOnFrontPage="true">IEEE</organization>
            </author>
            <date month="January" year="2022"/>
          </front>
          <seriesInfo name="DOI" value="10.1109/IEEESTD.2022.9690134"/>
          <seriesInfo name="IEEE Std" value="802.15.9-2021"/>
        </reference>
        <reference anchor="IPSP" target="https://www.bluetooth.com/specifications/specs/internet-protocol-support-profile-1-0/" quoteTitle="true" derivedAnchor="IPSP">
          <front>
            <title>Internet Protocol Support Profile 1.0</title>
            <author>
              <organization showOnFrontPage="true">Bluetooth</organization>
            </author>
            <date year="2014" month="December"/>
          </front>
        </reference>
        <reference anchor="KW03" quoteTitle="true" target="https://doi.org/10.1016/S1570-8705(03)00008-8" derivedAnchor="KW03">
          <front>
            <title>Secure routing in wireless sensor networks: attacks and countermeasures</title>
            <author fullname="Chris Karlof" initials="C." surname="Karlof"/>
            <author fullname="David Wagner" initials="D." surname="Wagner"/>
            <date month="September" year="2003"/>
          </front>
          <seriesInfo name="DOI" value="10.1016/S1570-8705(03)00008-8"/>
          <refcontent>Volume 1, Issues 2-3, Pages 293-315</refcontent>
        </reference>
        <reference anchor="LLCP-1.4" target="https://nfc-forum.org/build/specifications/logical-link-control-protocol-technical-specification/" quoteTitle="true" derivedAnchor="LLCP-1.4">
          <front>
            <title>Logical Link Control Protocol Technical Specification</title>
            <author>
              <organization showOnFrontPage="true">NFC Forum</organization>
            </author>
            <date month="December" year="2022"/>
          </front>
          <refcontent>Version 1.4</refcontent>
        </reference>
        <reference anchor="NETRICITY" target="https://www.netricity.org/" quoteTitle="true" derivedAnchor="NETRICITY">
          <front>
            <title>The Netricity program addresses the need for long range powerline networking for outside-the-home, smart meter-to-grid, and industrial control applications</title>
            <author>
              <organization showOnFrontPage="true">Netricity</organization>
            </author>
          </front>
        </reference>
        <reference anchor="RFC3756" target="https://www.rfc-editor.org/info/rfc3756" quoteTitle="true" derivedAnchor="RFC3756">
          <front>
            <title>IPv6 Neighbor Discovery (ND) Trust Models and Threats</title>
            <author fullname="P. Nikander" initials="P." role="editor" surname="Nikander"/>
            <author fullname="J. Kempf" initials="J." surname="Kempf"/>
            <author fullname="E. Nordmark" initials="E." surname="Nordmark"/>
            <date month="May" year="2004"/>
            <abstract>
              <t indent="0">The existing IETF standards specify that IPv6 Neighbor Discovery (ND) and Address Autoconfiguration mechanisms may be protected with IPsec Authentication Header (AH). However, the current specifications limit the security solutions to manual keying due to practical problems faced with automatic key management. 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 provides 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/rfc6282" quoteTitle="true" derivedAnchor="RFC6282">
          <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 indent="0">This document updates RFC 4944, "Transmission of IPv6 Packets over IEEE 802.15.4 Networks". This document specifies an IPv6 header compression format for IPv6 packet delivery in Low Power Wireless Personal Area Networks (6LoWPANs). The compression format relies on shared context to allow compression of arbitrary prefixes. How the information is maintained in that shared context is out of scope. This document specifies compression of multicast addresses and a framework for compressing next headers. UDP header compression is specified within 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/rfc6550" quoteTitle="true" derivedAnchor="RFC6550">
          <front>
            <title>RPL: IPv6 Routing Protocol for Low-Power and Lossy Networks</title>
            <author fullname="T. Winter" initials="T." role="editor" surname="Winter"/>
            <author fullname="P. Thubert" initials="P." role="editor" surname="Thubert"/>
            <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 indent="0">Low-Power and Lossy Networks (LLNs) are a class of network in which both the routers and their interconnect are constrained. LLN routers typically operate with constraints on processing power, memory, and energy (battery power). Their interconnects are characterized by high loss rates, low data rates, and instability. LLNs are comprised of anything from a few dozen to thousands of routers. Supported traffic flows include point-to-point (between devices inside the LLN), point-to-multipoint (from a central control point to a subset of devices inside the LLN), and multipoint-to-point (from devices inside the LLN towards a central control point). This document specifies the IPv6 Routing Protocol for Low-Power and Lossy Networks (RPL), which provides a mechanism whereby multipoint-to-point traffic from devices inside the LLN towards a central control point 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 also 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/rfc6620" quoteTitle="true" derivedAnchor="RFC6620">
          <front>
            <title>FCFS SAVI: First-Come, First-Served Source Address Validation Improvement 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-Abegnoli"/>
            <date month="May" year="2012"/>
            <abstract>
              <t indent="0">This memo describes First-Come, First-Served Source Address Validation Improvement (FCFS SAVI), a mechanism that provides source address validation for IPv6 networks using the FCFS principle. The proposed mechanism is intended 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/rfc6775" quoteTitle="true" derivedAnchor="RFC6775">
          <front>
            <title>Neighbor Discovery Optimization for IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs)</title>
            <author fullname="Z. Shelby" initials="Z." role="editor" surname="Shelby"/>
            <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 indent="0">The IETF work in IPv6 over Low-power Wireless Personal Area Network (6LoWPAN) defines 6LoWPANs such as IEEE 802.15.4. This and other similar link technologies have limited or no usage of multicast signaling due to energy conservation. In addition, the wireless network may not strictly follow the traditional concept of IP subnets and IP links. IPv6 Neighbor Discovery was not designed 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 impractical in a low-power and lossy network. This document describes simple optimizations to IPv6 Neighbor Discovery, its addressing mechanisms, and duplicate address detection for Low- power Wireless Personal Area Networks and similar networks. The document thus updates RFC 4944 to specify the use of the optimizations 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/rfc8065" quoteTitle="true" derivedAnchor="RFC8065">
          <front>
            <title>Privacy Considerations for IPv6 Adaptation-Layer Mechanisms</title>
            <author fullname="D. Thaler" initials="D." surname="Thaler"/>
            <date month="February" year="2017"/>
            <abstract>
              <t indent="0">This document discusses how a number of privacy threats apply to technologies designed for IPv6 over various link-layer protocols, and it provides advice to protocol designers on how to address such threats in adaptation-layer 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/rfc8066" quoteTitle="true" derivedAnchor="RFC8066">
          <front>
            <title>IPv6 over Low-Power Wireless Personal Area Network (6LoWPAN) ESC 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 indent="0">RFC 4944 defines the ESC dispatch type to allow additional dispatch 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 octet code points and listing registration entries for known use cases at the time of 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/rfc8138" quoteTitle="true" derivedAnchor="RFC8138">
          <front>
            <title>IPv6 over Low-Power Wireless Personal Area Network (6LoWPAN) Routing Header</title>
            <author fullname="P. Thubert" initials="P." role="editor" surname="Thubert"/>
            <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 indent="0">This specification introduces a new IPv6 over Low-Power Wireless Personal Area Network (6LoWPAN) dispatch type for use in 6LoWPAN route-over topologies, which initially covers the needs of Routing Protocol for Low-Power and Lossy Networks (RPL) data packet compression (RFC 6550). Using this dispatch type, this specification defines a method to compress the RPL Option (RFC 6553) information 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/rfc8352" quoteTitle="true" derivedAnchor="RFC8352">
          <front>
            <title>Energy-Efficient Features of Internet of Things Protocols</title>
            <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 indent="0">This document describes the challenges for energy-efficient protocol 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 upper-layer protocols so that they can together achieve an energy-efficient behavior. The document also provides an overview of energy-efficient mechanisms available at each layer of the IETF protocol suite specified for constrained-node networks.</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/rfc8376" quoteTitle="true" derivedAnchor="RFC8376">
          <front>
            <title>Low-Power Wide Area Network (LPWAN) Overview</title>
            <author fullname="S. Farrell" initials="S." role="editor" surname="Farrell"/>
            <date month="May" year="2018"/>
            <abstract>
              <t indent="0">Low-Power Wide Area Networks (LPWANs) are wireless technologies with characteristics such as large coverage areas, low bandwidth, possibly very small packet and application-layer data sizes, and long battery life operation. This memo is an informational overview of the set of LPWAN technologies being considered in the IETF and of the gaps that exist between the needs of those technologies 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/rfc8505" quoteTitle="true" derivedAnchor="RFC8505">
          <front>
            <title>Registration Extensions for IPv6 over Low-Power Wireless Personal Area Network (6LoWPAN) Neighbor Discovery</title>
            <author fullname="P. Thubert" initials="P." role="editor" surname="Thubert"/>
            <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 indent="0">This specification updates RFC 6775 -- the Low-Power Wireless Personal Area Network (6LoWPAN) Neighbor Discovery specification -- to clarify the role of the protocol as a registration technique and simplify the registration operation in 6LoWPAN routers, as well as to provide enhancements to the registration capabilities and mobility detection for different network topologies, including the Routing Registrars performing routing for host routes and/or proxy Neighbor 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/rfc8613" quoteTitle="true" derivedAnchor="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>
        <reference anchor="RFC8928" target="https://www.rfc-editor.org/info/rfc8928" quoteTitle="true" derivedAnchor="RFC8928">
          <front>
            <title>Address-Protected Neighbor Discovery for Low-Power and Lossy Networks</title>
            <author fullname="P. Thubert" initials="P." role="editor" surname="Thubert"/>
            <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 indent="0">This document updates the IPv6 over Low-Power Wireless Personal Area 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 extension 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 Registered Address and can be used to provide proof of ownership of the Registered Addresses. 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 information, 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/rfc8929" quoteTitle="true" derivedAnchor="RFC8929">
          <front>
            <title>IPv6 Backbone Router</title>
            <author fullname="P. Thubert" initials="P." role="editor" surname="Thubert"/>
            <author fullname="C.E. Perkins" initials="C.E." surname="Perkins"/>
            <author fullname="E. Levy-Abegnoli" initials="E." surname="Levy-Abegnoli"/>
            <date month="November" year="2020"/>
            <abstract>
              <t indent="0">This document updates RFCs 6775 and 8505 in order to enable proxy services for IPv6 Neighbor Discovery by Routing Registrars called "Backbone Routers". Backbone Routers are placed along the wireless edge of a backbone and federate 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/rfc9008" quoteTitle="true" derivedAnchor="RFC9008">
          <front>
            <title>Using RPI Option Type, Routing Header for Source Routes, and IPv6-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 indent="0">This document looks at different data flows through Low-Power and Lossy Networks (LLN) where RPL (IPv6 Routing Protocol for Low-Power and Lossy Networks) is used to establish routing. The document enumerates the cases where RPL Packet Information (RPI) Option Type (RFC 6553), RPL Source Route Header (RFC 6554), and IPv6-in-IPv6 encapsulation are required in the data plane. This analysis provides the basis upon which to design efficient compression of these headers. 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 updates RFC 8138 as well to consider the new Option Type when the RPL Option is decompressed.</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/rfc9010" quoteTitle="true" derivedAnchor="RFC9010">
          <front>
            <title>Routing for RPL (Routing Protocol for Low-Power and Lossy Networks) Leaves</title>
            <author fullname="P. Thubert" initials="P." role="editor" surname="Thubert"/>
            <author fullname="M. Richardson" initials="M." surname="Richardson"/>
            <date month="April" year="2021"/>
            <abstract>
              <t indent="0">This specification provides a mechanism for a host that implements a routing-agnostic interface based on IPv6 over Low-Power Wireless Personal Area Network (6LoWPAN) Neighbor Discovery to obtain reachability services across a network that leverages RFC 6550 for its routing operations. It updates RFCs 6550, 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/rfc9035" quoteTitle="true" derivedAnchor="RFC9035">
          <front>
            <title>A Routing Protocol for Low-Power and Lossy Networks (RPL) Destination-Oriented Directed Acyclic Graph (DODAG) Configuration Option for the 6LoWPAN Routing Header</title>
            <author fullname="P. Thubert" initials="P." role="editor" surname="Thubert"/>
            <author fullname="L. Zhao" initials="L." surname="Zhao"/>
            <date month="April" year="2021"/>
            <abstract>
              <t indent="0">This document updates RFC 8138 by defining a bit in the Routing Protocol for Low-Power and Lossy Networks (RPL) Destination-Oriented Directed Acyclic 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>
          <seriesInfo name="RFC" value="9035"/>
          <seriesInfo name="DOI" value="10.17487/RFC9035"/>
        </reference>
        <reference anchor="RFC9428" target="https://www.rfc-editor.org/info/rfc9428" quoteTitle="true" derivedAnchor="RFC9428">
          <front>
            <title>Transmission of IPv6 Packets over Near Field Communication</title>
            <author fullname="Y. Choi" initials="Y." role="editor" surname="Choi"/>
            <author fullname="Y-G. Hong" surname="Y-G. Hong"/>
            <author fullname="J-S. Youn" surname="J-S. Youn"/>
            <date month="July" year="2023"/>
            <abstract>
              <t indent="0">Near Field Communication (NFC) is a set of standards for smartphones and portable devices to establish radio communication with each other by touching them together or bringing them into proximity, usually no more than 10 cm apart. NFC standards cover communication protocols and data exchange formats and are based on existing Radio Frequency Identification (RFID) standards, including ISO/IEC 14443 and FeliCa. The standards include ISO/IEC 18092 and those defined by the NFC Forum. The NFC technology has been widely implemented and available in mobile phones, laptop computers, and many other devices. This document describes how IPv6 is transmitted over NFC using IPv6 over Low-Power Wireless Personal Area Network (6LoWPAN) techniques.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="9428"/>
          <seriesInfo name="DOI" value="10.17487/RFC9428"/>
        </reference>
        <reference anchor="I-D.ietf-iotops-security-protocol-comparison" target="https://datatracker.ietf.org/doc/html/draft-ietf-iotops-security-protocol-comparison-02" quoteTitle="true" derivedAnchor="SEC-PROT-COMP">
          <front>
            <title>Comparison of CoAP Security Protocols</title>
            <author initials="J." surname="Preuß Mattsson" fullname="John Preuß Mattsson">
              <organization showOnFrontPage="true">Ericsson AB</organization>
            </author>
            <author initials="F." surname="Palombini" fullname="Francesca Palombini">
              <organization showOnFrontPage="true">Ericsson AB</organization>
            </author>
            <author initials="M." surname="Vučinić" fullname="Mališa Vučinić">
              <organization showOnFrontPage="true">INRIA</organization>
            </author>
            <date month="April" day="11" year="2023"/>
          </front>
          <seriesInfo name="Internet-Draft" value="draft-ietf-iotops-security-protocol-comparison-02"/>
          <refcontent>Work in Progress</refcontent>
        </reference>
        <reference anchor="Thread" target="https://www.threadgroup.org/Support" quoteTitle="true" derivedAnchor="Thread">
          <front>
            <title>Resources</title>
            <author>
              <organization showOnFrontPage="true">Thread</organization>
            </author>
          </front>
        </reference>
        <reference anchor="TIA-485-A" target="https://global.ihs.com/doc_detail.cfm?item_s_key=00032964" quoteTitle="true" derivedAnchor="TIA-485-A">
          <front>
            <title>Electrical Characteristics of Generators and Receivers for Use in Balanced Digital Multipoint Systems</title>
            <author>
              <organization showOnFrontPage="true">TIA</organization>
            </author>
            <date month="March" year="1998"/>
          </front>
          <refcontent>TIA-485-A, Revision of TIA-485</refcontent>
        </reference>
        <reference anchor="TS102.939-1" target="https://www.etsi.org/deliver/etsi_ts/102900_102999/10293901/01.02.01_60/ts_10293901v010201p.pdf" quoteTitle="true" derivedAnchor="TS102.939-1">
          <front>
            <title>Digital Enhanced Cordless Telecommunications (DECT); Ultra Low Energy (ULE); Machine to Machine Communications; Part 1: Home Automation Network (phase 1)</title>
            <author>
              <organization showOnFrontPage="true">ETSI</organization>
            </author>
            <date month="March" year="2015"/>
          </front>
          <seriesInfo name="ETSI-TS" value="102 939-1"/>
          <refcontent>V1.2.1</refcontent>
        </reference>
        <reference anchor="TS102.939-2" target="https://www.etsi.org/deliver/etsi_ts/102900_102999/10293902/01.01.01_60/ts_10293902v010101p.pdf" quoteTitle="true" derivedAnchor="TS102.939-2">
          <front>
            <title>Digital Enhanced Cordless Telecommunications (DECT); Ultra Low Energy (ULE); Machine to Machine Communications; Part 2: Home Automation Network (phase 2)</title>
            <author>
              <organization showOnFrontPage="true">ETSI</organization>
            </author>
            <date month="March" year="2015"/>
          </front>
          <seriesInfo name="ETSI TS" value="102 939-2"/>
          <refcontent>V1.1.1</refcontent>
        </reference>
        <reference anchor="Wi-SUN" target="https://www.wi-sun.org" quoteTitle="true" derivedAnchor="Wi-SUN">
          <front>
            <title>Wi-SUN Alliance</title>
            <author/>
          </front>
        </reference>
      </references>
    </references>
    <section anchor="appendix-a" numbered="true" toc="include" removeInRFC="false" pn="section-appendix.a">
      <name slugifiedName="name-design-space-dimensions-for">Design Space Dimensions for 6lo Deployment</name>
      <t indent="0" pn="section-appendix.a-1"><xref target="RFC6568" format="default" sectionFormat="of" derivedContent="RFC6568"/> lists the dimensions used to describe the design space of wireless sensor networks in the context of the 6LoWPAN Working Group. The design space is already limited by the unique characteristics of a LoWPAN (e.g., low power, short range, low bit rate). 

In <xref target="RFC6568" sectionFormat="of" section="2" format="default" derivedLink="https://rfc-editor.org/rfc/rfc6568#section-2" derivedContent="RFC6568"/>, the following design space dimensions are described: Deployment, Network Size, Power Source, Connectivity, Multi-Hop Communication, Traffic Pattern, Mobility, and Quality of Service (QoS). However, in this document, the following design space dimensions are considered:</t>
      <dl spacing="normal" newline="true" indent="3" pn="section-appendix.a-2">
        <dt pn="section-appendix.a-2.1">Deployment/Bootstrapping:</dt>
        <dd pn="section-appendix.a-2.2">6lo nodes can be connected randomly or in an organized manner. The
	bootstrapping has different characteristics for each link-layer
	technology.</dd>
        <dt pn="section-appendix.a-2.3">Topology:</dt>
        <dd pn="section-appendix.a-2.4">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 pn="section-appendix.a-2.5">L2-mesh or L3-mesh:</dt>
        <dd pn="section-appendix.a-2.6">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 pn="section-appendix.a-2.7">Multi-link Subnet and Single Subnet:</dt>
        <dd pn="section-appendix.a-2.8">The selection of a multi-link subnet and a single subnet depends on
	connectivity and the number of 6lo nodes.</dd>
        <dt pn="section-appendix.a-2.9">Data Rate:</dt>
        <dd pn="section-appendix.a-2.10">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 pn="section-appendix.a-2.11">Buffering Requirements:</dt>
        <dd pn="section-appendix.a-2.12">Some 6lo use case may require a higher data rate than the link-layer
	technology support. In this case, a buffering mechanism, telling the
	application to throttle its generation of data, and compression of the
	data are possible to manage the data.</dd>
        <dt pn="section-appendix.a-2.13">Security and Privacy Requirements:</dt>
        <dd pn="section-appendix.a-2.14">Some 6lo use cases can involve transferring some important and
	personal data between 6lo nodes. In this case, high-level security
	support is required.</dd>
        <dt pn="section-appendix.a-2.15">Mobility across 6lo Networks and Subnets:</dt>
        <dd pn="section-appendix.a-2.16">The movement of 6lo nodes depends on the 6lo use case. If the 6lo
	nodes can move or be moved around, a mobility management mechanism is
	required.</dd>
        <dt pn="section-appendix.a-2.17">Time Synchronization Requirements:</dt>
        <dd pn="section-appendix.a-2.18">The requirement of time synchronization of the upper-layer service
	is dependent on the use case. For some 6lo use cases related to health
	service, the measured data must be recorded with the exact time.</dd>
        <dt pn="section-appendix.a-2.19">Reliability and QoS:</dt>
        <dd pn="section-appendix.a-2.20">Some 6lo use cases require high reliability, for example,
	real-time or health-related services.</dd>
        <dt pn="section-appendix.a-2.21">Traffic Patterns:</dt>
        <dd pn="section-appendix.a-2.22">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 pn="section-appendix.a-2.23">Security Bootstrapping:</dt>
        <dd pn="section-appendix.a-2.24">Without the external operations, 6lo nodes must have a security
	bootstrapping mechanism. </dd>
        <dt pn="section-appendix.a-2.25">Power Use Strategy:</dt>
        <dd pn="section-appendix.a-2.26">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" sectionFormat="of" derivedContent="RFC7228"/>. Each link-layer technology defines a particular power use strategy that may be
	tuned <xref target="RFC8352" format="default" sectionFormat="of" derivedContent="RFC8352"/>. Readers are expected
	to be familiar with the terminology found in <xref target="RFC7228" format="default" sectionFormat="of" derivedContent="RFC7228"/>.</dd>
        <dt pn="section-appendix.a-2.27">Update Firmware Requirements:</dt>
        <dd pn="section-appendix.a-2.28">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 pn="section-appendix.a-2.29">Wired vs. Wireless:</dt>
        <dd pn="section-appendix.a-2.30">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>
    <section anchor="Acknowledgements" numbered="false" toc="include" removeInRFC="false" pn="section-appendix.b">
      <name slugifiedName="name-acknowledgements">Acknowledgements</name>
      <t indent="0" pn="section-appendix.b-1"><contact fullname="Carles Gomez"/> has been funded in part by the
      Spanish Government through the Jose Castillejo CAS15/00336 grant, the
      TEC2016-79988-P grant, and the PID2019-106808RA-I00 grant as well as by
      Secretaria d'Universitats i Recerca del Departament d'Empresa i
      Coneixement de la Generalitat de Catalunya through grants 2017 SGR 376 and 2021 SGR 00330. His contribution to this work has been carried out in part during
      his stay as a visiting scholar at the Computer Laboratory of the
      University of Cambridge. </t>
      <t indent="0" pn="section-appendix.b-2"><contact fullname="Thomas Watteyne"/>, <contact fullname="Pascal       Thubert"/>, <contact fullname="Xavier Vilajosana"/>, <contact fullname="Daniel Migault"/>, <contact fullname="Jianqiang Hou"/>,
      <contact fullname="Kerry Lynn"/>, <contact fullname="S.V.R. Anand"/>,
      and <contact fullname="Seyed Mahdi Darroudi"/> have provided valuable
      feedback for this document.</t>
      <t indent="0" pn="section-appendix.b-3"><contact fullname="Das Subir"/> and <contact fullname="Michel       Veillette"/> have provided valuable information of jupiterMesh, and
      <contact fullname="Paul Duffy"/> has provided valuable information of
      Wi-SUN for this document. Also, <contact fullname="Jianqiang Hou"/> has
      provided valuable information of G3-PLC and Netricity for this
      document. <contact fullname="Take Aanstoot"/>, <contact fullname="Kerry       Lynn"/>, and <contact fullname="Dave Robin"/> have provided valuable
      information of MS/TP and practical use case of MS/TP for this document.</t>
      <t indent="0" pn="section-appendix.b-4"><contact fullname="Deoknyong Ko"/> has provided relevant text of
      LTE-MTC, and he shared his experience to deploy IPv6 and 6lo technologies
      over LTE MTC in SK Telecom.</t>
    </section>
    <section anchor="authors-addresses" numbered="false" removeInRFC="false" toc="include" pn="section-appendix.c">
      <name slugifiedName="name-authors-addresses">Authors' Addresses</name>
      <author fullname="Yong-Geun Hong" initials="Y-G" surname="Hong">
        <organization showOnFrontPage="true">Daejeon University</organization>
        <address>
          <postal>
            <street>62 Daehak-ro, Dong-gu</street>
            <city>Daejeon</city>
            <region/>
            <code>34520</code>
            <country>South Korea</country>
          </postal>
          <phone>+82 42 280 4841</phone>
          <email>yonggeun.hong@gmail.com</email>
        </address>
      </author>
      <author initials="C." surname="Gomez" fullname="Carles Gomez">
        <organization abbrev="UPC" showOnFrontPage="true">Universitat Politecnica de Catalunya</organization>
        <address>
          <postal>
            <street>C/Esteve Terradas, 7</street>
            <code>08860</code>
            <city>Castelldefels</city>
            <country>Spain</country>
          </postal>
          <email>carles.gomez@upc.edu</email>
        </address>
      </author>
      <author fullname="Younghwan Choi" initials="Y." surname="Choi">
        <organization abbrev="ETRI" showOnFrontPage="true">ETRI</organization>
        <address>
          <postal>
            <street>218 Gajeongno, Yuseong</street>
            <city>Daejeon</city>
            <region/>
            <code>34129</code>
            <country>South Korea</country>
          </postal>
          <phone>+82 42 860 1429</phone>
          <email>yhc@etri.re.kr</email>
        </address>
      </author>
      <author fullname="Abdur Rashid Sangi" initials="A." surname="Sangi">
        <organization showOnFrontPage="true">Wenzhou-Kean University</organization>
        <address>
          <postal>
            <street>88 Daxue Road, Ouhai, Wenzhou</street>
            <city>Zhejiang</city>
            <region/>
            <code>325060</code>
            <country>China</country>
          </postal>
          <phone/>
          <email>sangi_bahrian@yahoo.com</email>
        </address>
      </author>
      <author fullname="Samita Chakrabarti" initials="S." surname="Chakrabarti">
        <organization showOnFrontPage="true">Verizon</organization>
        <address>
          <postal>
            <street/>
            <city>Bedminster</city>
            <region>NJ</region>
            <code/>
            <country>United States of America</country>
          </postal>
          <phone/>
          <email>samita.chakrabarti@verizon.com</email>
        </address>
      </author>
    </section>
  </back>
</rfc>
