<?xml version='1.0' encoding='utf-8'?> version="1.0" encoding="UTF-8"?>

<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
  <!ENTITY nbsp    "&#160;">
  <!ENTITY zwsp   "&#8203;">
  <!ENTITY nbhy   "&#8209;">
  <!ENTITY wj     "&#8288;">
]>
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" submissionType="IETF" category="std" consensus="true" docName="draft-ietf-6lo-plc-12" category="std">
	<?rfc compact="yes"?>
	<?rfc text-list-symbols="o-*+"?>
	<?rfc subcompact="no"?>
	<?rfc sortrefs="yes"?>
	<?rfc symrefs="yes"?>
	<?rfc strict="yes"?>
	<?rfc toc="yes"?> number="9354" ipr="trust200902" obsoletes="" updates="" xml:lang="en" sortRefs="true" symRefs="true" tocInclude="true" version="3">

  <!-- xml2rfc v2v3 conversion 3.15.0 -->
  <front>

    <title abbrev="IPv6 over PLC">
		Transmission PLC">Transmission of IPv6 Packets over PLC Power Line Communication (PLC) Networks</title>
    <seriesInfo name="RFC" value="9354"/>
    <author fullname="Jianqiang Hou" initials="J." surname="Hou">
	<organization> Huawei Technologies </organization>
      <organization>Huawei Technologies</organization>
      <address>
        <postal>
          <street>101 Software Avenue,</street>
		<street>Nanjing 210012</street>
		<street>China</street>
          <city>Nanjing</city>
	  <code>210012</code>
          <country>China</country>
        </postal>
        <email>houjianqiang@huawei.com</email>
      </address>
    </author>
    <author fullname="Bing Liu" initials="B." surname="Liu">
      <organization>Huawei Technologies</organization>
      <address>
        <postal>
	  <extaddr>Haidian District</extaddr>
          <street>No. 156 Beiqing Rd. Haidian District,</street>
		<street>Beijing 100095</street>
		<street>China</street> Rd.</street>
          <city>Beijing</city>
	  <code>100095</code>
          <country>China</country>
        </postal>
        <email>remy.liubing@huawei.com</email>
      </address>
    </author>
    <author fullname="Yong-Geun Hong" initials="Y-G." surname="Hong">
      <organization>Daejeon University</organization>
      <address>
        <postal>
	  <extaddr>Dong-gu</extaddr>
          <street>62 Daehak-ro, Dong-gu</street>
		<street>Daejeon  34520</street>
		<street>Korea</street> Daehak-ro</street>
          <city>Daejeon</city>
	  <code>34520</code>
          <country>Republic of Korea</country>
        </postal>
        <email>yonggeun.hong@gmail.com</email>
      </address>
    </author>
    <author fullname="Xiaojun Tang" initials="X." surname="Tang">
      <organization abbrev="SGEPRI">
		State Grid Electric Power Research Institute</organization>
      <address>
        <postal>
          <street>19 Chengxin Avenue</street>
		<street>Nanjing 211106</street>
		<street>China</street>
          <city>Nanjing</city>
	  <code>211106</code>
          <country>China</country>
        </postal>
        <email>itc@sgepri.sgcc.com.cn</email>
      </address>
    </author>
    <author fullname="Charles E. Perkins" initials="C.E." initials="C." surname="Perkins">
      <organization>Lupin Lodge</organization>
      <address>
        <phone/>
        <email>charliep@computer.org</email>
	<!-- uri and facsimile elements may also be added -->
      </address>
    </author>
    <date year="2023" month="January" />
    <workgroup>6Lo Working Group</workgroup>

    <abstract><t>
    <area>int</area>
    <workgroup>6lo</workgroup>

<keyword>6lo</keyword>
<keyword>6lowpan</keyword>
<keyword>6lo-plc</keyword>
<keyword>6loplc</keyword>
<keyword>plc</keyword>

    <abstract>
      <t>
	Power Line Communication (PLC), namely using the electric-power electric power lines
	for indoor and outdoor communications, has been widely applied to
	support Advanced Metering Infrastructure (AMI), especially smart
	meters for electricity.  The existing electricity infrastructure
	facilitates the expansion of PLC deployments due to its potential
	advantages in terms of cost and convenience.  Moreover, a wide variety
	of accessible devices raises the potential demand of IPv6 for future
	applications. This document describes how IPv6 packets are transported
	over constrained PLC networks, such as those described in ITU-T G.9903,
        IEEE 1901.1 1901.1, and IEEE 1901.2.
      </t>
    </abstract>
  </front>
  <middle>
    <section title="Introduction" anchor="Intro"> anchor="Intro" numbered="true" toc="default">
      <name>Introduction</name>
      <t>
	The idea of using power lines for both electricity supply and
	communication can be traced back to the beginning of the last century.
	Using the existing power grid to transmit messages, Power Line
	Communication (PLC) is a good candidate for supporting various service
	scenarios such as in houses and offices, in trains and vehicles, in
	smart grid grids, and advanced metering infrastructure in Advanced Metering Infrastructure (AMI) <xref target="SCENA"/>.
	target="SCENA" format="default"/>.  The data acquisition data-acquisition devices in
	these scenarios share common features such as fixed position, large quantity,
	quantity of nodes, low data rate rate, and low power consumption.</t>
      <t>
	Although PLC technology has evolved over several decades, it has not
	been fully adapted for IPv6-based constrained networks.  The
	resource-constrained IoT-related scenarios related to the Internet of Things (IoT)
	lie in the low voltage PLC networks with most applications in the area
	of Advanced Metering
	Infrastructure (AMI), Vehicle-to-Grid AMI, vehicle-to-grid communications, in-home energy management, and
	smart street lighting.  IPv6 is important for PLC networks, due to its
	large address space and efficient address
	auto-configuration. autoconfiguration.
      </t>
      <t>
	This document provides a brief overview of PLC technologies. Some of
	them have LLN (low power (Low-Power and lossy network) Lossy Network) characteristics, i.e.,
	limited power consumption, memory memory, and processing resources. This
	document specifies the transmission of IPv6 packets over those "constrained"
	constrained PLC networks.  The general approach is to adapt elements
	of the 6LoWPAN (IPv6 over Low-Power Wireless Personal Area Network)
	and 6lo (IPv6 over Networks of Resource-constrained Nodes)
	specifications, such as those described in <xref target="RFC4944"/>, target="RFC4944"
	format="default"/>, <xref target="RFC6282"/>, target="RFC6282" format="default"/>, <xref target="RFC6775"/>
	target="RFC6775" format="default"/>, and <xref target="RFC8505"/> target="RFC8505"
	format="default"/>, to constrained PLC networks.
      </t>
    </section>
    <!-- end section "Introduction" -->

<section title="Requirements anchor="Term" numbered="true" toc="default">
      <name>Requirements Notation and Terminology" anchor="Term"> Terminology</name>
        <t>
    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
    NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
    "<bcp14>MAY</bcp14>", and
   "OPTIONAL" "<bcp14>OPTIONAL</bcp14>" in this document are to be interpreted as
    described in
   BCP14 BCP&nbsp;14 <xref target="RFC2119"/> <xref target="RFC8174"/>
    when, and only when, they appear in all capitals, as shown here.
        </t>
      <t> This document uses the following acronyms and terminologies:
	<list hangIndent="6" style="hanging">
	<t hangText="6BBR:">
      </t>
      <dl newline="false" spacing="normal">
        <dt>6BBR:</dt>
        <dd> 6LoWPAN Backbone Router </t>
	<t hangText="6LBR:"> </dd>
        <dt>6LBR:</dt>
        <dd> 6LoWPAN Border Router</t>
	<t hangText="6LoWPAN:"> Router</dd>
        <dt>6lo:</dt>
        <dd> IPv6 over Networks of Resource-constrained Nodes </dd>
        <dt>6LoWPAN:</dt>
        <dd> IPv6 over Low-Power Wireless Personal Area Network </t>
	<t hangText="6lo:"> IPv6 over Networks of Resource-constrained Nodes </t>
	<t hangText="6LR:"> </dd>
        <dt>6LR:</dt>
        <dd> 6LoWPAN Router</t>
	<t hangText="AMI:"> Router</dd>
        <dt>AMI:</dt>
        <dd> Advanced Metering Infrastructure </t>
	<t hangText="BBPLC:"> </dd>
        <dt>BBPLC:</dt>
        <dd> Broadband Power Line Communication </t>
	<t hangText="Coordinator:"> </dd>
        <dt>Coordinator:</dt>
        <dd> A device capable of relaying messages</t>
	<t hangText="DAD:"> messages</dd>
        <dt>DAD:</dt>
        <dd> Duplicate Address Detection </t>
	<t hangText="IID:"> IPv6 Interface </dd>
	<dt>EUI:</dt>
	<dd>Extended Unique Identifier</dd>
        <dt>IID:</dt>
        <dd>Interface Identifier </t>
	<t hangText="LLN:"> Low power </dd>
        <dt>LLN:</dt>
        <dd> Low-Power and Lossy Network </t>
	<t hangText="MTU:"> </dd>
        <dt>MTU:</dt>
        <dd> Maximum Transmission Unit </t>
	<t hangText="NBPLC:"> </dd>
        <dt>NBPLC:</dt>
        <dd> Narrowband Power Line Communication </t>
	<t hangText="PAN:"> </dd>
        <dt>PAN:</dt>
        <dd> Personal Area Network </t>
	<t hangText="PANC:"> </dd>
        <dt>PANC:</dt>
        <dd> PAN Coordinator, a coordinator which that also acts as the
		primary controller of a PAN</t>
	<t hangText="PLC:"> PAN</dd>
        <dt>PLC:</dt>
        <dd> Power Line Communication </t>
	<t hangText="PLC device:"> </dd>
        <dt>PLC device:</dt>
        <dd> An entity that follows the PLC standards and
		implements the protocol stack described in this draft</t>
	<t hangText="RPL:"> IPv6 Routing document</dd>
        <dt>RA:</dt>
        <dd> Router Advertisement </dd>
        <dt>RPL:</dt>
        <dd>Routing Protocol for Low-Power
				and Lossy Networks </t> </dd>
      </dl>
      <t hangText="RA:"> Router Advertisement </t>
	</list>
	</t>

	<texttable anchor="Term_mapping" title="Terminology Mapping between PLC
		standards">
         <preamble>Below keepWithNext="true">Below is a mapping table of the terminology between
          <xref target="IEEE_1901.2"/>, target="IEEE_1901.2" format="default"/>, <xref target="IEEE_1901.1"/>, target="IEEE_1901.1" format="default"/>, <xref target="ITU-T_G.9903"/> target="ITU-T_G.9903" format="default"/>, and this document.</preamble>

         <ttcol document.</t>
      <table anchor="Term_mapping" align="center">
        <name>Terminology Mapping between PLC Standards</name>
        <thead>
          <tr>
            <th align="center">IEEE 1901.2</ttcol>

         <ttcol 1901.2</th>
            <th align="center">IEEE 1901.1</ttcol>

		 <ttcol 1901.1</th>
            <th align="center">ITU-T G.9903</ttcol>

		 <ttcol G.9903</th>
            <th align="center">This document</ttcol>

		 <c>PAN Coordinator</c>
         <c>Central Coordinator</c>
		 <c>PAN Coordinator</c>
		 <c>PAN Coordinator</c>
		 <c> </c>
		 <c> </c>
		 <c> </c>
		 <c> </c>
		 <c>Coordinator</c>
         <c>Proxy Coordinator</c>
         <c>Full-function device</c>
		 <c>Coordinator</c>
		 <c> </c>
		 <c> </c>
		 <c> </c>
		 <c> </c>
         <c>Device</c>
         <c>Station</c>
         <c>PAN Device</c>
		 <c>PLC Device</c>

    </texttable> document</th>
          </tr>
        </thead>
        <tbody>
          <tr>
            <td align="center">PAN Coordinator</td>
            <td align="center">Central Coordinator</td>
            <td align="center">PAN Coordinator</td>
            <td align="center">PAN Coordinator</td>
          </tr>
          <tr>
            <td align="center">Coordinator</td>
            <td align="center">Proxy Coordinator</td>
            <td align="center">Full-Function Device</td>
            <td align="center">Coordinator</td>
          </tr>
          <tr>
            <td align="center">Device</td>
            <td align="center">Station</td>
            <td align="center">PAN Device</td>
            <td align="center">PLC Device</td>
          </tr>
        </tbody>
      </table>
    </section>
    <!-- end section "Requirements Notation and Terminology" -->

<section title="Overview anchor="Overview" numbered="true" toc="default">
      <name>Overview of PLC" anchor="Overview"> PLC</name>
      <t>

	PLC technology enables convenient two-way communications for home
	users and utility companies to monitor and control electric plugged electrically connected
	devices such as electricity meters and street lights. PLC can also be
	used in smart home scenarios, such as the control of indoor lights and
	switches. Due to the large range of communication frequencies, PLC is
	generally classified into two categories: Narrowband PLC (NBPLC) for
	automation of sensors (which have a low frequency band and low power cost),
	cost) and Broadband PLC (BBPLC) for home and industry networking
	applications.
      </t>

      <t>
	Various standards have been addressed on the MAC and PHY layers
	Media Access Control (MAC) and Physical (PHY) layers. For example, standards for
	this communication technology, e.g., BBPLC (1.8-250
        MHz) including include IEEE 1901 and ITU-T G.hn, and standards for
	NBPLC (3-500 kHz) including include ITU-T G.9902 (G.hnem), ITU-T G.9903
	(G3-PLC) <xref target="ITU-T_G.9903"/>, target="ITU-T_G.9903" format="default"/>, ITU-T G.9904
	(PRIME), IEEE 1901.2 <xref target="IEEE_1901.2"/>  (a
	combination of G3-PLC and PRIME PLC) <xref target="IEEE_1901.2" format="default"/>, and IEEE 1901.2a
	<xref target="IEEE_1901.2a"/> (an amendment to IEEE 1901.2).
	1901.2) <xref target="IEEE_1901.2a" format="default"/>.
      </t>
      <t>
	A new PLC standard
	IEEE 1901.1 <xref
	target="IEEE_1901.1"/>, which target="IEEE_1901.1" format="default"/>, a PLC standard that is aimed at the medium frequency band of less
	than 12 MHz, has been was published by the IEEE standard for Smart Grid
	Powerline Communication Working Group (SGPLC WG). IEEE 1901.1 balances
	the needs for bandwidth versus communication range, range and is thus a
	promising option for 6lo applications.
      </t>
      <t>
	This specification is focused on IEEE 1901.1, IEEE 1901.2, and ITU-T G.9903.
      </t>
      <section title="Protocol Stack" anchor="stack"> anchor="stack" numbered="true" toc="default">
        <name>Protocol Stack</name>
        <t>
	The protocol stack for IPv6 over PLC is illustrated in <xref target="fig-stack"/>.
	target="fig-stack" format="default"/>.  The PLC MAC/PHY layer corresponds MAC and PLC PHY layers
	correspond to the layers described in IEEE 1901.1, IEEE 1901.2 1901.2, or ITU-T G.9903.  The 6lo
	adaptation layer for PLC is illustrated in <xref target="v6overPLC"/>. target="v6overPLC"
	format="default"/>.  For multihop tree and mesh topologies, a routing
	protocol is likely to be necessary.  The routes can be built in
	mesh-under mode at layer Layer 2 or in route-over mode at layer-3, Layer 3, as
	explained in Sections <xref target="Routing" format="counter"/> and <xref target="Routing"/>. target="nd" format="counter"/>. </t>

        <figure title="PLC Protocol Stack" anchor="fig-stack">
    <artwork><![CDATA[
          <name>PLC Protocol Stack</name>
          <artwork name="" type="" align="left" alt=""><![CDATA[
                 +----------------------------------------+
                 |           Application Layer            |
                 +----------------------------------------+
                 |            Transport Layer             |
                 +----------------------------------------+
                 |                                        |
                 |               IPv6 Layer               |
                 |                                        |
                 +----------------------------------------+
                 |   Adaptation layer Layer for IPv6 over PLC   |
                 +----------------------------------------+
                 |             PLC MAC Layer              |
                 +----------------------------------------+
                 |             PLC PHY Layer              |
                 +----------------------------------------+
]]></artwork>
        </figure>
      </section>
      <!-- end section "Protocol Stack" -->

    <section title="Addressing Modes" anchor="Addressing"> anchor="Addressing" numbered="true" toc="default">
        <name>Addressing Modes</name>
        <t>
	Each PLC device has a globally unique long address of 48-bits
	(<xref target="IEEE_1901.1"/>) 48 bits <xref
	target="IEEE_1901.1" format="default"/> or 64-bits (<xref target="IEEE_1901.2"/>, 64 bits <xref
	target="IEEE_1901.2" format="default"/> <xref target="ITU-T_G.9903"/>) target="ITU-T_G.9903"
	format="default"/> and a short address of 12-bits
	(<xref target="IEEE_1901.1"/>) 12 bits <xref
	target="IEEE_1901.1" format="default"/> or 16-bits (<xref target="IEEE_1901.2"/>, 16 bits <xref
	target="IEEE_1901.2" format="default"/> <xref target="ITU-T_G.9903"/>). target="ITU-T_G.9903"
	format="default"/>.  The long address is set by the manufacturer
	according to the IEEE EUI-48 MAC address
	or the IEEE EUI-64 address.  Each PLC device joins the network by
	using the long address and communicates with other devices by using
	the short address after joining the network. Short addresses can be
	assigned during the onboarding process, by the PANC or the JRC (join
	registrar/coordinator) in CoJP (Constrained Join Protocol) <xref target="I-D.ietf-6tisch-minimal-security"/>.
	target="RFC9031" format="default"/>.
        </t>
      </section>
      <!-- end section "Addressing Modes" -->

    <section title="Maximum anchor="mtu" numbered="true" toc="default">
        <name>Maximum Transmission Unit" anchor="mtu"> Unit</name>
        <t>
	The Maximum Transmission Unit (MTU) of the MAC layer determines whether
	fragmentation and reassembly are needed at the adaptation layer of
	IPv6 over PLC.  IPv6 requires an MTU of 1280 octets or greater; thus thus,
	for a MAC layer with an MTU lower than this limit,
	fragmentation and reassembly at the adaptation layer are required.
        </t>
        <t>
	The IEEE 1901.1 MAC supports upper layer upper-layer packets up to 2031 octets.
	The IEEE 1901.2 MAC layer supports an MTU of 1576 octets (the original
	value of 1280 bytes was updated in 2015 <xref target="IEEE_1901.2a"/>). target="IEEE_1901.2a"
	format="default"/>).  Though these two technologies can support
	IPv6 originally without fragmentation and reassembly, it is possible
	to configure a smaller MTU in a high-noise communication environment.
	Thus
	Thus, the 6lo functions, including header compression, fragmentation fragmentation,
	and reassembly, are still applicable and useful.
        </t>
        <t>
	The MTU for ITU-T G.9903 is 400 octets, which is insufficient for
	supporting IPv6's MTU.  For this reason, fragmentation and reassembly is
	are required for G.9903-based networks to carry IPv6.
        </t>
      </section>
      <!-- end section "Maximum Transmission Unit" -->

    <section title="Routing Protocol" anchor="Routing"> anchor="Routing" numbered="true" toc="default">
        <name>Routing Protocol</name>
        <t>
	Routing protocols suitable for use in PLC networks include:
	<list style="symbols">
	<t> RPL
        </t>
        <ul spacing="normal">
          <li>RPL (Routing Protocol for Low-Power and Lossy Networks) <xref target="RFC6550"/>
          target="RFC6550" format="default"/> is a layer-3 Layer 3 routing protocol.
          AODV-RPL <xref target="I-D.ietf-roll-aodv-rpl"/> target="I-D.ietf-roll-aodv-rpl" format="default"/>
          updates RPL to include reactive, point-to-point, and asymmetric
          routing.  IEEE 1901.2 specifies Information Elements (IEs) with MAC
          layer metrics, which can be provided to L3 a Layer 3 routing protocol for
          parent
	    selection.
	</t>
	<t> IEEE selection.</li>
          <li>IEEE 1901.1 supports the mesh-under routing scheme.  Each PLC
          node maintains a routing table, in which each route entry comprises
          the short addresses of the destination and the related next hop.
          The route entries are built during the network establishment via a
          pair of association request/confirmation messages.  The route
          entries can be changed via a pair of proxy change
          request/confirmation messages. These association and proxy change
          messages must be approved by the central coordinator (PANC in this
          document).
	</t>
	<t> LOADng (The Lightweight
	</li>
          <li>LOADng (Lightweight On-demand Ad hoc Distance vector
          routing protocol, Next Generation) is a reactive protocol operating
          at layer-2 Layer 2 or layer-3. Layer 3.  Currently, LOADng is supported in ITU-T
          G.9903 <xref
			target="ITU-T_G.9903"/>, target="ITU-T_G.9903" format="default"/>, and the IEEE
          1901.2 standard refers to ITU-T G.9903 for LOAD-based networks.
	</t>
	</list>
    </t>
	</li>
        </ul>
      </section>
      <!-- end section "Routing Protocol" -->
</section>
    <!-- end section "Overview of PLC" -->

<section title="IPv6 anchor="v6overPLC" numbered="true" toc="default">
      <name>IPv6 over PLC" anchor="v6overPLC"> PLC</name>
      <t>
    A PLC node distinguishes between an IPv6 PDU and a non-IPv6 PDU based on
    the equivalent of
    a EtherType an Ethertype in a layer-2 Layer 2 PLC PDU. <xref target="RFC7973"/> target="RFC7973"
    format="default"/> defines a an Ethertype of "A0ED" for LoWPAN encapsulation,
    and this information can be carried in the IE field in the MAC header of
    <xref target="IEEE_1901.2"/> target="IEEE_1901.2" format="default"/> or <xref target="ITU-T_G.9903"/>.
    target="ITU-T_G.9903" format="default"/>.  And regarding <xref target="IEEE_1901.1"/>,
    target="IEEE_1901.1" format="default"/>, the IP packet type has been
    defined with the corresponding MAC Service Data Unit (MSDU) type value 49.
    And the 4-bit Internet Protocol version number in the IP header helps to
    distinguish between an IPv4 PDU and an IPv6 PDU.
</t>
      <t>
    6LoWPAN and 6lo standards standards, as described in <xref target="RFC4944"/>, target="RFC4944"
    format="default"/>, <xref target="RFC6282"/>, target="RFC6282" format="default"/>, <xref target="RFC6775"/>,
    target="RFC6775" format="default"/>, and <xref target="RFC8505"/> target="RFC8505"
    format="default"/>, provide useful functionality functionality, including link-local IPv6
    addresses, stateless address auto-configuration, autoconfiguration, neighbor discovery,
    header compression, fragmentation, and reassembly.  However, due to the
    different characteristics of the PLC media, the 6LoWPAN adaptation layer,
    as it is, cannot perfectly fulfill the requirements of PLC
    environments. These considerations suggest the need for a dedicated
    adaptation layer for PLC, which is detailed in the following
    subsections.</t>
      <section title="Stateless anchor="slaac" numbered="true" toc="default">
        <name>Stateless Address Autoconfiguration" anchor="slaac"> Autoconfiguration</name>
        <t>
	To obtain an IPv6 Interface Identifier (IID), a PLC device performs
	stateless address autoconfiguration <xref target="RFC4944"/>. target="RFC4944"
	format="default"/>.  The autoconfiguration can be based on either a
	long or short link-layer address.
        </t>
        <t>
	The IID can be based on the device's 48-bit MAC address or its EUI-64
	identifier <xref target="EUI-64"/>. target="EUI-64" format="default"/>.  A 48-bit MAC
	address MUST <bcp14>MUST</bcp14> first be extended to a 64-bit Interface ID IID
	by inserting 0xFFFE at the fourth and fifth octets as specified in
	<xref target="RFC2464"/>. target="RFC2464" format="default"/>.  The IPv6 IID is derived
	from the 64-bit Interface ID IID by inverting the U/L (Universal/Local)
	bit <xref target="RFC4291"/>. target="RFC4291" format="default"/>.
        </t>
        <t>
	For IEEE 1901.2 and ITU-T G.9903, a 48-bit "pseudo-address" is formed
	by the 16-bit PAN ID, 16 zero bits bits, and the 16-bit short address as
	follows:
        </t>
    <t>	<list hangIndent="4" style="hanging">
	<t>
          <t indent="3"> 16_bit_PAN:0000:16_bit_short_address </t>
	</list>
    </t>
        <t>
	Then, the 64-bit Interface ID MUST IID <bcp14>MUST</bcp14> be derived by inserting the 16-bit
	0xFFFE into as follows:
        </t>
    <t>	<list hangIndent="4" style="hanging">
	<t>
          <t indent="3"> 16_bit_PAN:00FF:FE00:16_bit_short_address </t>
	</list>
    </t>
        <t>
	For the 12-bit short addresses used by IEEE 1901.1, the 48-bit
	pseudo-address is formed by a 24-bit NID (Network IDentifier, Identifier, YYYYYY),
	12 zero bits bits, and a 12-bit TEI (Terminal Equipment Identifier, XXX) as follows:
        <list hangIndent="4" style="hanging">
	<t>
        </t>
          <t indent="3"> YYYY:YY00:0XXX </t>
        </list>
        <t>
	The 64-bit Interface ID MUST IID <bcp14>MUST</bcp14> be derived by inserting the 16-bit 0xFFFE
	into this 48-bit pseudo-address as follows:
        <list hangIndent="4" style="hanging">
	<t>
        </t>
          <t indent="3"> YYYY:YYFF:FE00:0XXX </t>
        </list>
        <t>
	As investigated in <xref target="RFC7136"/>, besides target="RFC7136" format="default"/>, aside from the method discussed in
	<xref target="RFC4291"/>,
	some target="RFC4291" format="default"/>, other IID generation
	IID-generation methods defined in by the IETF do not imply any additional semantics for the "Universal/Local"
	Universal/Local (U/L) bit (bit 6) and the Individual/Group bit (bit 7),
	so that
	7). Therefore, these two bits are not reliable indicators for their original meanings.
	Thus indicators.  Thus, when using an IID derived by a short address,
	the operators of the PLC network can choose whether or not to comply with the original
	meaning of these two bits or not. bits.  If so, they choose to
  comply with the original meaning, these two bits <bcp14>MUST</bcp14>
	both be set to zero, since the IID derived from the short address is not global,
	these two bits MUST both be set to zero. global. In order to avoid any ambiguity in the derived
	Interface ID,
	IID, these two bits MUST NOT <bcp14>MUST NOT</bcp14> be a valid part
	of the PANID PAN ID (for IEEE 1901.2 and ITU-T G.9903) or NID (for IEEE
	1901.1). For example, the
	PANID PAN ID or NID must always be chosen so that
	the two bits are zeros; zeros or the high
	6 six bits in PANID PAN ID or NID are left
	shifted by 2 two bits. If not, they choose not to comply with the original meaning, the operator must be aware that these two
	bits are not reliable indicators, and the IID cannot be transformed
	back into a short link layer link-layer address via a reverse operation of the
	mechanism presented above. However, the short address can still be
	obtained via the Unicast Address Mapping mechanism described in <xref target="unicast-map"/>.
	target="unicast-map" format="default"/>.
        </t>
        <t>
	For privacy reasons, the IID derived from the MAC address (with
	padding and bit clamping) SHOULD <bcp14>SHOULD</bcp14> only be used for
	link-local address configuration.  A PLC host SHOULD <bcp14>SHOULD</bcp14>
	use the IID derived from the link-layer short link-layer address to configure
	IPv6 addresses used for communication with the public network;
	otherwise, the host's MAC address is exposed. As per <xref target="RFC8065"/>,
	target="RFC8065" format="default"/>, when short addresses are used on
	PLC links, a shared secret key or version number from the
	Authoritative Border Router Option <xref target="RFC6775"/> target="RFC6775"
	format="default"/> can be used to improve the entropy of the hash input, thus
	input. Thus, the generated IID can be spread out to the full range of
	the IID address space while stateless address compression is still
	allowed. The By default, the hash algorithm by default of
	the implementations SHOULD
	<bcp14>SHOULD</bcp14> be SHA256, using the version number, the PANID/NID
	PAN ID or NID, and the short address as the input arguments, and the 256-bits
	256-bit hash output is truncated into the IID by taking the high 64
	bits.
        </t>
      </section>
      <!-- end section "Stateless Address Autoconfiguration" -->

    <section title="IPv6 Link Local Address" anchor="link-local"> anchor="link-local" numbered="true" toc="default">
        <name>IPv6 Link-Local Address</name>
        <t>
	The IPv6 link-local address <xref target="RFC4291"/> target="RFC4291" format="default"/> for a PLC
	interface is formed by appending the IID, as defined
	above, to the prefix FE80::/64 (see <xref target="fig-link-local"/>). target="fig-link-local" format="default"/>).
        </t>
        <figure title="IPv6 Link Local anchor="fig-link-local">
          <name>IPv6 Link-Local Address for a PLC interface"
						anchor="fig-link-local">
    <artwork><![CDATA[ Interface</name>
          <artwork name="" type="" align="left" alt=""><![CDATA[
    10 bits           54 bits                   64 bits
  +----------+-----------------------+----------------------------+
  |1111111010|        (zeros)        |    Interface Identifier    |
  +----------+-----------------------+----------------------------+
]]></artwork>
        </figure>
      </section>
      <!-- end section "IPv6 Link Local Address" -->

    <section title="Unicast anchor="unicast-map" numbered="true" toc="default">
        <name>Unicast Address Mapping" anchor="unicast-map"> Mapping</name>
        <t>
	The address resolution address-resolution procedure for mapping IPv6 unicast addresses
	into PLC link-layer addresses follows the general description in
	section 7.2 of <xref target="RFC4861"/>.
	target="RFC4861" sectionFormat="of" section="7.2"/>. <xref target="RFC6775"/>
	target="RFC6775" format="default"/> improves this procedure by
	eliminating usage of multicast NS. NS (Neighbor Solicitation). The
	resolution is realized by the NCEs (neighbor cache entry) entries) created
	during the address registration at the routers.  <xref
		target="RFC8505"/>
	target="RFC8505" format="default"/> further improves the registration
	procedure by enabling multiple LLNs to form an IPv6 subnet, subnet and by
	inserting a link-local address registration to better serve proxy
	registration of new devices.
        </t>
        <section title="Unicast anchor="Unicast-1901.1" numbered="true" toc="default">
          <name>Unicast Address Mapping for IEEE 1901.1"
						anchor="Unicast-1901.1"> 1901.1</name>
          <t>
	    The Source/Target Link-layer Source Link-Layer Address and Target Link-Layer Address
	    options for IEEE_1901.1 used in the Neighbor Solicitation NS and Neighbor
	    Advertisement (NA) have the following form.
          </t>
          <figure title="Unicast anchor="fig-unicast-1901.1">
            <name>Unicast Address Mapping for IEEE 1901.1"
		anchor="fig-unicast-1901.1"> <artwork> <![CDATA[ 1901.1</name>
            <artwork name="" type="" align="left" alt=""><![CDATA[
  0                   1                   2                   3
  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |     Type      |    Length=1   |              NID              :
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 :NID (continued)|  Padding (all zeros)  |          TEI          |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]>
            </artwork>
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 ]]></artwork>
          </figure>
	</t>
          <t> Option fields:
	    <list hangIndent="6" style="hanging">
	    <t hangText="Type:"> 1
          </t>
          <dl newline="false" spacing="normal">
            <dt>Type:</dt>
            <dd>1 for Source Link-layer Link-Layer Address and 2 for Target Link-layer Link-Layer Address. </t>
	    <t hangText="Length:"> The </dd>
            <dt>Length:</dt>
            <dd>The length of this option (including type Type and length Length fields)
            in units of 8 octets.  The value of this field is 1 for the 12-bit
            IEEE 1901.1 PLC short addresses. </t>
	    <t hangText="NID:"> 24-bit </dd>
            <dt>NID:</dt>
            <dd>24-bit Network IDentifier </t>
	    <t hangText="Padding:"> 12 Identifier</dd>
            <dt>Padding:</dt>
            <dd>12 zero bits </t>
	    <t hangText="TEI:"> 12-bit </dd>
            <dt>TEI:</dt>
            <dd>12-bit Terminal Equipment Identifier </t>
	    </list>
	</t> Identifier</dd>
          </dl>
        </section>
        <!-- end "Unicast Address Mapping for IEEE 1901.1" -->

	<section
	    title="Unicast anchor="Unicast-1901.2" numbered="true" toc="default">
          <name>Unicast Address Mapping for IEEE 1901.2 and ITU-T G.9903"
	    anchor="Unicast-1901.2"> G.9903</name>
          <t>
	    The Source/Target Link-layer Source Link-Layer Address and Target Link-Layer Address options for IEEE_1901.2 and ITU-T G.9903 used in the Neighbor Solicitation
	    NS and Neighbor
	    Advertisement NA have the following form.
          </t>
          <figure title="Unicast anchor="fig-unicast-1901.2">
            <name>Unicast Address Mapping for IEEE 1901.2"
		anchor="fig-unicast-1901.2">
	    <artwork><![CDATA[ 1901.2</name>
            <artwork name="" type="" align="left" alt=""><![CDATA[
   0                   1                   2                   3
   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |     Type      |    Length=1   |             PAN ID            |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |       Padding (all zeros)     |         Short Address         |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
          </figure>
	</t>

	<t> Option
          <t>Option fields:
	    <list hangIndent="6" style="hanging">
	    <t hangText="Type:"> 1
          </t>
          <dl newline="false" spacing="normal">
            <dt>Type:</dt>
            <dd>1 for Source Link-layer Link-Layer Address and 2 for Target Link-layer Address. </t>
	    <t hangText="Length:"> The Link-Layer Address.</dd>
            <dt>Length:</dt>
            <dd>The length of this option (including type Type and length Length fields)
            in units of 8 octets.  The value of this field is 1 for the 16-bit
            IEEE 1901.2 PLC short addresses. </t>
	    <t hangText="PAN ID:"> 16-bit </dd>
            <dt>PAN ID:</dt>
            <dd>16-bit PAN IDentifier </t>
	    <t hangText="Padding:"> 16 IDentifier</dd>
            <dt>Padding:</dt>
            <dd>16 zero bits </t>
	    <t hangText="Short Address:"> 16-bit bits</dd>
            <dt>Short Address:</dt>
            <dd>16-bit short address </t>
	    </list>
	</t> address</dd>
          </dl>
        </section>
        <!-- end "Unicast Address Mapping for IEEE 1901.2" -->
    </section>
      <section title="Neighbor Discovery" anchor="nd"> anchor="nd" numbered="true" toc="default">
        <name>Neighbor Discovery</name>
        <t>
	Neighbor discovery procedures for 6LoWPAN networks are described in
	Neighbor Discovery Optimization for 6LoWPANs
	<xref target="RFC6775"/> target="RFC6775"
	format="default"/> and <xref target="RFC8505"/>. target="RFC8505" format="default"/>.
	These optimizations support the registration of sleeping hosts.
	Although PLC devices are electrically powered, sleeping mode SHOULD
	<bcp14>SHOULD</bcp14> still be used for power saving.
        </t>
        <t>
	For IPv6 prefix dissemination, Router Solicitations (RS) (RSs) and Router
	Advertisements (RA) MAY (RAs) <bcp14>MAY</bcp14> be used as per <xref target="RFC6775"/>.
	target="RFC6775" format="default"/>. If the PLC network uses route-over,
	route-over mode, the IPv6 prefix MAY <bcp14>MAY</bcp14> be disseminated by
	the
	layer-3 Layer 3 routing protocol, such as RPL, which may include the
	prefix in the DIO (DODAG Information Object) message. As per <xref target="RFC9010"/>,
	target="RFC9010" format="default"/>, it is possible to have PLC
	devices configured as RPL-unaware-leaves, RPL-unaware leaves, which do not participate in
	RPL at all, along with RPL-aware PLC devices. In this case, the prefix
	dissemination SHOULD <bcp14>SHOULD</bcp14> use the RS/RA messages.
        </t>
        <t>
	For dissemination of context information dissemination, Router Advertisements (RA) MUST information, RAs <bcp14>MUST</bcp14> be used
	as per <xref target="RFC6775"/>. target="RFC6775" format="default"/>. The 6LoWPAN context
	option (6CO) MUST <bcp14>MUST</bcp14> be included in the RA to disseminate
	the Context IDs used for prefix and/or address compression.
        </t>
        <t>
	For address registration in route-over mode, a PLC device MUST
	<bcp14>MUST</bcp14> register its addresses by sending a unicast
	link-local Neighbor
	Solicitation NS to the 6LR. If the registered address is link-local, link local, the
	6LR
	SHOULD NOT <bcp14>SHOULD NOT</bcp14> further register it to the registrar (6LBR,
	(6LBR or 6BBR). Otherwise, the address MUST <bcp14>MUST</bcp14> be registered
	via an ARO (Address Registration Option) or EARO (Extended Address
	Registration Option) included in the DAR (<xref
		target="RFC6775"/>) (Duplicate Address Request)
	<xref target="RFC6775" format="default"/> or EDAR (<xref target="RFC8505"/>) (Extended Duplicate
	Address Request) <xref target="RFC8505" format="default"/>
	messages. For
	RFC8505 compliant PLC devices, devices compliant with <xref target="RFC8505"/>, the
	'R' flag in the EARO MUST <bcp14>MUST</bcp14> be set when sending Neighbor Solicitations NSs in
	order to extract the status information in the replied Neighbor Advertisements NAs from the
	6LR. If DHCPv6 is used to assign addresses or the IPv6 address is
	derived from the unique long or short link layer link-layer address, Duplicate
	Address Detection (DAD) SHOULD NOT <bcp14>SHOULD NOT</bcp14> be utilized.
	Otherwise, the DAD MUST <bcp14>MUST</bcp14> be performed at the 6LBR (as per
	<xref
		target="RFC6775"/>) target="RFC6775" format="default"/>) or proxied by the routing
	registrar (as per <xref
		target="RFC8505"/>). target="RFC8505" format="default"/>). The
	registration status is fed back via the DAC (Duplicate Address
	Confirmation) or EDAC (Extended Duplicate Address Confirmation)
	message from the 6LBR and the Neighbor Advertisement (NA) NA from the 6LR. The section 6 of  <xref target="RFC8505"/> target="RFC8505"
	sectionFormat="of" section="6"/> shows how RFC6775-only devices that only behave as specified in <xref target="RFC6775"/> can work
	with RFC8505-updated devices. devices that have been updated per <xref target="RFC8505"/>.
        </t>
        <t>
	For address registration in mesh-under mode, since all the PLC devices
	are link-local neighbors to the 6LBR, DAR/DAC or EDAR/EDAC messages
	are not required. A PLC device MUST <bcp14>MUST</bcp14> register its
	addresses by sending a unicast NS message with an ARO or EARO. The
	registration status is fed back via the NA message from the 6LBR.
        </t>
      </section>
      <!-- end section "Neighbor Discovery" -->

    <section title="Header Compression" anchor="Compression"> anchor="Compression" numbered="true" toc="default">
        <name>Header Compression</name>
        <t>
	The compression of
        IPv6 datagrams within header compression in PLC MAC frames refers to is based on <xref target="RFC6282"/>, which target="RFC6282"
        format="default"/> (which updates <xref target="RFC4944"/>.
	Header compression as defined in target="RFC4944"
        format="default"/>). <xref target="RFC6282"/> which target="RFC6282" format="default"/> specifies
        the compression format for IPv6 datagrams on top of IEEE 802.15.4, 802.15.4;
        therefore, this format is the basis used for IPv6 header compression in PLC. of IPv6 datagrams within
        PLC MAC frames. For situations when the PLC
	MAC MTU cannot support the 1280-octet IPv6 packet, the headers MUST
	<bcp14>MUST</bcp14> be compressed according to <xref target="RFC6282"/> the encoding formats, formats
	specified in <xref target="RFC6282" format="default"/>, including the
	Dispatch Header, the LOWPAN_IPHC LOWPAN_IPHC, and the compression residu residue carried in-line.
	inline.
        </t>
        <t>
	For IEEE 1901.2 and ITU-T G.9903, the IP header compression follows the
	instruction in <xref target="RFC6282"/>. target="RFC6282" format="default"/>. However,
	additional adaptation
	MUST <bcp14>MUST</bcp14> be considered for IEEE
	1901.1 since it has a short address of 12 bits instead of 16 bits. The
	only modification is the semantics of the "Source Address Mode" and
	the "Destination Address Mode" when set as "10" in the section 3.1 of <xref target="RFC6282"/>,
	target="RFC6282" sectionFormat= "of" section="3.1"/>, which is
	illustrated as following. follows.
        </t>
	<t>
	SAM:
        <t>SAM: Source Address Mode:
	</t>
	<t>
	If Mode:</t>
        <t>If SAC=0: Stateless compression
	<list hangIndent="6" style="hanging">
	<t hangText="10:"> 16 compression</t>
        <dl newline="false" spacing="normal" indent="6">
          <dt>10:</dt>
          <dd>16 bits. The first 112 bits of the address are elided. The value
          of the first 64 bits is the link-local prefix padded with zeros. The
          following 64 bits are 0000:00ff:fe00:0XXX, where 0XXX are the 16
          bits carried in-line, inline, in which the first 4 bits are zero. </t>
	</list>
	</t>
	<t>
	If </dd>
        </dl>
        <t>If SAC=1: stateful Stateful context-based compression
	<list hangIndent="6" style="hanging">
	<t hangText="10:"> 16 compression</t>
        <dl newline="false" spacing="normal" indent="6">
          <dt>10:</dt>
          <dd>16 bits. The address is derived using context information and
          the 16 bits carried in-line. inline. Bits covered by context information are
          always used. Any IID bits not covered by context information are
          taken directly from their corresponding bits in the mapping between the
          16-bit to short address and the IID mapping given as provided by 0000:00ff:fe00:0XXX,
          where 0XXX are the 16 bits
          carried in-line, inline, in which the first 4 bits are zero. Any remaining
          bits are zero. </t>
	</list>
	</t>

	<t>
	DAM: </dd>
        </dl>
        <t>DAM: Destination Address Mode:
	</t>
	<t>
	If Mode:</t>
        <t>If M=0 and DAC=0: Stateless compression
	<list hangIndent="6" style="hanging">
	<t hangText="10:"> 16 compression</t>
        <dl newline="false" spacing="normal" indent="6">
          <dt>10:</dt>
          <dd>16 bits. The first 112 bits of the address are elided.  The
          value of the first 64 bits is the link-local prefix padded with
          zeros.  The following 64 bits are 0000:00ff:
            fe00:0XXX, 0000:00ff:fe00:0XXX, where 0XXX
          are the 16 bits carried in-line, inline, in which the first 4 bits are zero.  </t>
	</list>
	</t>
	<t>
	If
          </dd>
        </dl>
        <t>If M=0 and DAC=1: stateful Stateful context-based compression
	<list hangIndent="6" style="hanging">
	<t hangText="10:"> 16 compression</t>
        <dl newline="false" spacing="normal" indent="6">
          <dt>10:</dt>
          <dd>16 bits. The address is derived using context information and
          the 16 bits carried in-line. inline.  Bits covered by context information
          are always used.  Any IID bits not covered by context information
          are taken directly from their corresponding bits in the mapping between
          the 16-bit to short address and the IID mapping given as provided by 0000:00ff:fe00:0XXX,
          where 0XXX are the 16 bits
          carried in-
            line, inline, in which the first 4 bits are zero.  Any remaining
          bits are zero. </t>
	</list>
	</t> </dd>
        </dl>
      </section>
      <!-- end section "Header Compression" -->

    <section title="Fragmentation anchor="frag" numbered="true" toc="default">
        <name>Fragmentation and Reassembly" anchor="frag"> Reassembly</name>
        <t>
	The constrained PLC MAC layer provides the function functions of fragmentation
	and reassembly.  However, fragmentation and reassembly is are still
	required at the adaptation layer, layer if the MAC layer cannot support the
	minimum MTU demanded by IPv6, which is 1280 octets.  </t>
        <t>
	In IEEE 1901.1 and IEEE 1901.2, the MAC layer supports payloads as big
	as 2031 octets and 1576 octets octets, respectively. However, when the
	channel condition is noisy, smaller packets have a higher transmission
	success rate, and the operator can choose to configure smaller MTU at
	the MAC layer. If the configured MTU is smaller than 1280 octets, the
	fragmentation and reassembly defined in <xref target="RFC4944"/> MUST target="RFC4944"
	format="default"/> <bcp14>MUST</bcp14> be used.
        </t>
        <t>
	In ITU-T G.9903, the maximum MAC payload size is fixed to 400 octets,
	so to cope with the required MTU of 1280 octets by IPv6,
	fragmentation and reassembly at the 6lo adaptation layer MUST <bcp14>MUST</bcp14> be provided
	as specified in <xref target="RFC4944"/>. target="RFC4944" format="default"/>.
        </t>
        <t>
	<xref target="RFC4944"/> target="RFC4944" format="default"/> uses a 16-bit datagram tag
	to identify the fragments of the same IP packet. <xref target="RFC4963"/>
	target="RFC4963" format="default"/> specifies that at high data rates,
	the 16-bit IP identification field is not large enough to prevent
	frequent incorrectly assembled IP fragments.
For constrained PLC, the data rate is much lower than the situation mentioned
in RFC4963, thus <xref target="RFC4963"/>; thus, the 16-bit tag is sufficient to assemble
the fragments correctly.
        </t>
      </section>
      <!-- end section "Fragmentation and Reassembly" -->

</section>
    <!-- end section "IPv6 over Narrowband PLC" -->

<section title="Internet anchor="Topologies" numbered="true" toc="default">
      <name>Internet Connectivity Scenarios and Topologies"
	anchor="Topologies"> Topologies</name>
      <t>
    The PLC network model can be simplified to two kinds of network device: devices:
    PAN Coordinator (PANC) and PLC Device. device.  The PANC is the primary
    coordinator of the PLC subnet and can be seen as a primary node; PLC Devices
    devices are typically PLC meters and sensors.  The address registration
    and DAD features can also be deployed on the PANC, for example example, the 6LBR
    <xref target="RFC6775"/> target="RFC6775" format="default"/> or the routing registrar in
    <xref target="RFC8505"/>. target="RFC8505" format="default"/>. IPv6 over PLC networks are
    built as trees, meshes tree, mesh, or stars topology star topologies according to the use cases.
    Generally, each PLC network has one PANC. In some cases, the PLC network
    can have alternate coordinators to replace the PANC when the PANC leaves
    the network for some reason.  Note that the PLC topologies in this section
    are based on logical connectivity, not physical links. The term "PLC
    subnet" refers to a multilink subnet, in which the PLC devices share the
    same address prefix.
</t>
      <t>
    The star topology is common in current PLC scenarios.  In single-hop star
    topologies, communication at the link layer only takes place between a PLC Device
    device and a PANC.  The PANC typically collects data (e.g., a meter
    reading) from the PLC devices, devices and then concentrates and uploads the data
    through Ethernet or Cellular cellular networks (see <xref target="fig-plc-star"/>). target="fig-plc-star"
    format="default"/>).  The collected data is transmitted by the smart
    meters through PLC, aggregated by a concentrator, and sent to the utility and
    then to a Meter Data Management System for data storage, analysis analysis, and
    billing.  This topology has been widely applied in the deployment of smart
    meters, especially in apartment buildings.
</t>
      <figure title="PLC anchor="fig-plc-star">
        <name>PLC Star Network connected Connected to the Internet"
	anchor="fig-plc-star">
<artwork><![CDATA[ Internet</name>
        <artwork name="" type="" align="left" alt=""><![CDATA[
                PLC Device   PLC Device
                      \        /           +---------
                       \      /           /
                        \    /           +
                         \  /            |
       PLC Device ------ PANC ===========+  Internet
                         /  \            |
                        /    \           +
                       /      \           \
                      /        \           +---------
                PLC Device   PLC Device

             <---------------------->
            PLC subnet (IPv6 over PLC)
]]></artwork>
      </figure>
      <t>
    A tree topology is useful when the distance between a device A and the PANC is
    beyond the PLC allowed PLC-allowed limit and there is another device B in between
    able to communicate with both sides.  Device B in this case acts both as both
    a PLC Device device and a Coordinator.

    For this scenario, the link layer link-layer
    communications take place between device A and device B, and between
    device B and PANC.  An example of a PLC tree network is depicted
    in <xref target="fig-plc-tree"/>. target="fig-plc-tree" format="default"/>.  This topology can be applied in
    smart street lighting, where the lights adjust the brightness to reduce
    energy consumption while sensors are deployed on the street-lights street lights to
    provide information such as light intensity, temperature, and humidity.
    The data transmission data-transmission distance in the street lighting scenario is normally
    above several kilometers, thus kilometers; thus, a PLC tree network is required.  A more
    sophisticated AMI network may also be constructed into the tree topology
    which
    that is depicted in <xref target="RFC8036"/>. target="RFC8036" format="default"/>.  A tree topology is suitable
    for AMI scenarios that require large coverage but low density,
    e.g., the deployment of smart meters in rural areas.  RPL is suitable
    for maintenance of a tree topology in which there is no need for
    communication directly between PAN devices.
</t>
      <figure title="PLC anchor="fig-plc-tree">
        <name>PLC Tree Network connected Connected to the Internet"
	anchor="fig-plc-tree">
<artwork><![CDATA[ Internet</name>
        <artwork name="" type="" align="left" alt=""><![CDATA[
                       PLC Device
                            \                   +---------
            PLC Device A     \                 /
                    \         \               +
                     \         \              |
              PLC Device B -- PANC ===========+  Internet
                     /         /              |
                    /         /               +
   PLC Device---PLC Device   /                 \
                            /                   +---------
           PLC Device---PLC Device

         <------------------------->
         PLC subnet (IPv6 over PLC)
]]></artwork>
      </figure>

      <t>
   Mesh networking in PLC is of great has many potential applications and has been
   studied for several years.  By connecting all nodes with their neighbors
   in communication range (see <xref target="fig-plc-mesh"/>), target="fig-plc-mesh" format="default"/>), a mesh
   topology dramatically enhances the communication efficiency and thus
   expands the size of PLC networks.  A simple use case is the smart home
   scenario where the ON/OFF state of air conditioning is controlled by
   the state of home lights (ON/OFF) and doors (OPEN/CLOSE). AODV-RPL (<xref target="I-D.ietf-roll-aodv-rpl"/>) <xref target="I-D.ietf-roll-aodv-rpl" format="default"/>
   enables direct communication between PLC device to PLC device communication, devices, without being obliged
   to transmit frames through the PANC, which is a requirement often cited
   for the AMI infrastructure.

</t>
      <figure title="PLC anchor="fig-plc-mesh">
        <name>PLC Mesh Network connected Connected to the Internet"
	anchor="fig-plc-mesh">
<artwork><![CDATA[ Internet</name>
        <artwork name="" type="" align="left" alt=""><![CDATA[
             PLC Device---PLC Device
                 / \        / \                   +---------
                /   \      /   \                 /
               /     \    /     \               +
              /       \  /       \              |
       PLC Device--PLC Device---PANC ===========+  Internet
              \       /  \       /              |
               \     /    \     /               +
                \   /      \   /                 \
                 \ /        \ /                   +---------
             PLC Device---PLC Device

     <------------------------------->
         PLC subnet (IPv6 over PLC)
]]></artwork>
      </figure>
    </section>
    <section title="Operations anchor="OAM" numbered="true" toc="default">
      <name>Operations and Manageability Considerations" anchor="OAM"> Considerations</name>
      <t>
	The constrained
	Constrained PLC networks are not managed in the same way as an
	enterprise
	network networks or a carrier network. networks. Constrained PLC networks,
	like the other IoT networks, are designed to be self-organized and
	self-managed. The software or firmware is flashed into the devices
	before deployment by the vendor or operator. And during the deployment
	process, the devices are bootstrapped, and no extra configuration is
	needed to get the devices connected to each other. Once a device
	becomes offline, it goes back to the bootstrapping stage and tries to
	rejoin the network. The onboarding status of the devices and the
	topology of the PLC network can be visualized via the PANC. The recently-formed iotops
	recently formed IOTOPS WG in the IETF is aiming aims to identify the
	requirements in IoT network management, and operational practices will
	be published. Developers and operators of PLC networks should be able
	to learn operational experiences from this WG.
      </t>
    </section>
    <section title="IANA Considerations" anchor="IANA"> anchor="IANA" numbered="true" toc="default">
      <name>IANA Considerations</name>
      <t>
	There are
	This document has no IANA considerations related to this document. actions.
      </t>
    </section>
    <section title="Security Considerations" anchor="Security"> anchor="Security" numbered="true" toc="default">
      <name>Security Considerations</name>
      <t>
	Due to the high accessibility of power grids, PLC might be susceptible
	to eavesdropping within its communication coverage, e.g., one
	apartment tenant may have the chance to monitor the other smart
	meters in the same apartment building. Link layer Link-layer security mechanisms,
	such as payload encryption and devcie device authentication,
	are designed in the PLC technologies mentioned in this document.
	Additionally, an on-path malicious PLC device could eavesdrop or modify
	packets sent through it if appropriate confidentiality and integrity
	mechanisms are not implemented.
      </t>

      <t>
	Malicious PLC devices could paralyze the whole network via DOS DoS
	attacks, e.g., keep joining and leaving the network frequently, frequently or
	sending multicast routing messages containing fake metrics. A device
	may also inadvertently join a wrong or even malicious network,
	exposing its data to malicious users. When communicating with a device
	outside the PLC network, the traffic has to go through the PANC. Thus Thus,
	the PANC must be a trusted entity. Moreover, the PLC network must
	prevent malicious devices to join in from joining the network. Thus Mutual Thus, mutual
	authentication of a PLC network and a new device is important, and it
	can be conducted during the onboarding process of the new
	device. Methods include protocols such as the TLS/DTLS Profile <xref target="RFC7925"/> target="RFC7925"
	format="default"/> (exchanging pre-installed certificates over DTLS),
	the Constrained Join Protocol (CoJP) <xref target="I-D.ietf-6tisch-minimal-security"/> target="RFC9031" format="default"/> (which uses pre-shared
	keys), and Zero-Touch Secure Join <xref target="I-D.ietf-6tisch-dtsecurity-zerotouch-join"/>
	(a target="I-D.ietf-6tisch-dtsecurity-zerotouch-join"
	format="default"/> (an IoT version of BRSKI, the Bootstrapping Remote Secure Key Infrastructure (BRSKI), which uses IDevID an Initial
	Device Identifier (IDevID) and MASA a Manufacturer Authorized Signing
	Authority (MASA) service to facilitate authentication). It is also
	possible to use EAP Extensible Authentication Protocol (EAP) methods such
	as the one defined in <xref target="I-D.ietf-emu-eap-noob"/> target="RFC9140" format="default"/> via transports like
	PANA
	Protocol for Carrying Authentication for Network Access (PANA) <xref target="RFC5191"/>.
	target="RFC5191" format="default"/>. No specific mechanism is
	specified by this document, as an appropriate mechanism will depend
	upon deployment circumstances. In some cases, the PLC devices can be
	deployed in uncontrolled places, where the devices may be accessed
	physically and be compromised via key extraction. Since
	the The compromised
	device may be still able to join in the network since its credentials
	are still valid. When group-shared symmetric keys are used in the
	network, the consequence is even more severe, i.e., the whole network
	or a large part of the network is at risk. Thus Thus, in scenarios where the
	physical attacks is are considered to be relatively highly possible,
	per device
	per-device credentials SHOULD <bcp14>SHOULD</bcp14> be used. Moreover,
	additional end-to-end security services"
	is a services are complementary to the network side
	network-side security mechanisms, e.g., if a devices device is compromised and
	 it
	has joined in the network, and then it claims itself as the PANC and
	 try
	tries to make the rest of the devices join its network. In this
	situation, the real PANC can send an alarm to the operator to
	acknowledge the risk.  Other behavior analysis behavior-analysis mechanisms can be
	deployed to recoginize recognize the malicious PLC devices by inspecting the
	packets and the data.
      </t>
      <t>
	IP addresses may be used to track devices on the Internet; such
	devices can often in turn be linked to individuals and their
	activities.  Depending on the application and the actual use pattern,
	this may be undesirable.  To impede tracking, globally unique and
	non-changing characteristics of IP addresses should be avoided, e.g.,
	by frequently changing the global prefix and avoiding unique
	link-layer derived IIDs in addresses. <xref target="RFC8065"/> target="RFC8065"
	format="default"/> discusses the privacy threats when interface identifiers (IID) are an IID is generated without sufficient entropy, including
	correlation of activities over time, location tracking,
	device-specific vulnerability exploitation, and address scanning. And
	an effective way to deal with these threats is to have enough entropy
	in the IID compairing compared to the link lifetime.  Consider a PLC network
	with 1024 devices and its a link lifetime is 8 years, according to
	the formula in RFC8065, <xref target="RFC8065" format="default"/>, an entropy
	of 40 bits is sufficient.  Padding the short address (12 or 16 bits)
	to generate the IID of a routable IPv6 address in the public network
	may be vulnerable to deal with address scans.
	Thus  Thus, as suggest suggested in the section 4.1,
	<xref target="slaac"/>, a hash function can be used to generate a 64 bits 64-bit
	IID.  When the version number of the PLC network is changed, the
	IPv6 addresses can be changed as well.  Other schemes such as limited
	lease period in DHCPv6 <xref target="RFC8415"/>, target="RFC8415" format="default"/>,
	Cryptographically Generated Addresses (CGAs) <xref target="RFC3972"/>, target="RFC3972"
	format="default"/>, Temporary Address Extensions <xref target="RFC8981"/>,
	target="RFC8981" format="default"/>, Hash-Based Addresses (HBAs) <xref target="RFC5535"/>,
	target="RFC5535" format="default"/>, or semantically opaque addresses
	<xref target="RFC7217"/> SHOULD target="RFC7217" format="default"/> <bcp14>SHOULD</bcp14> be
	used to enhance the IID privacy.
      </t>
    </section>

<section title="Acknowledgements" anchor="Ack">
    <t>
<!--  CEP: Was it intended to specifically acknowledge the 6LoWPAN working
           group, which has since been closed?  -->
	We gratefully acknowledge suggestions from the members of the IETF
	6lo working group.  Great thanks to
	Samita Chakrabarti and Gabriel Montenegro for their feedback and
	support in connecting the IEEE and ITU-T sides.  The authors thank Scott
	Mansfield, Ralph Droms, and Pat Kinney for their guidance in the liaison
	process.  The authors wish to thank Stefano Galli, Thierry Lys, Yizhou Li,
	Yuefeng Wu, and Michael Richardson for their valuable comments and contributions.
	The authors wish to thank Carles Gomez for shephering this document. The authors also thank Paolo Volpato for
	delegating the presentation at IETF 113.
	Sincere acknoledgements to the valuable comments from reviewers: Dave Thaler, Dan Romascanu,
	Murray Kucherawy, Benjamin Kaduk, Alvaro Retana, Éric Vyncke, Meral Shirazipour, Roman Danyliw and Lars Eggert.
    </t>
</section>
  </middle>
  <back>
<references title="Normative References">

<displayreference target="I-D.ietf-roll-aodv-rpl" to="AODV-RPL"/>
<displayreference target="I-D.ietf-6tisch-dtsecurity-zerotouch-join" to="ZEROTOUCH"/>

    <references>
      <name>References</name>
      <references>
        <name>Normative References</name>
        <reference anchor="IEEE_1901.2"
	target="https://standards.ieee.org/findstds/standard/1901.2-2013.html"> target="https://ieeexplore.ieee.org/document/6679210">
          <front>
            <title> IEEE Standard for Low-Frequency (less than 500 kHz)
		    Narrowband Power Line Communications for Smart Grid
		    Applications
            </title>
            <author>
		<organization> IEEE-SA Standards Board </organization>
              <organization>IEEE</organization>
            </author>
            <date month="October" month="December" year="2013"/>
          </front>
	  <seriesInfo name="IEEE" name="DOI" value="10.1109/IEEESTD.2013.6679210"/>
          <seriesInfo name="IEEE Std" value="1901.2"/>
        </reference>

        <reference anchor="ITU-T_G.9903" target="https://www.itu.int/rec/T-REC-G.9903">
          <front>
	    <title> Narrowband
            <title>Narrowband orthogonal frequency division
            multiplexing power line communication transceivers for G3-PLC
            networks
            </title>
            <author>
	    <organization> International Telecommunication Union</organization>
              <organization>ITU-T</organization>
            </author>
            <date month="August" year="2017"/>
          </front>
          <seriesInfo name="ITU-T" name="ITU-T Recommendation" value="G.9903"/>
        </reference>

	<?rfc include='reference.RFC.2119.xml'?>
	<?rfc include='reference.RFC.2464.xml'?>
	<?rfc include='reference.RFC.4291.xml'?>
	<?rfc include='reference.RFC.4861.xml'?>
	<?rfc include='reference.RFC.4944.xml'?>
	<?rfc include='reference.RFC.6282.xml'?>
	<?rfc include='reference.RFC.7136.xml'?>
	<?rfc include='reference.RFC.6550.xml'?>
	<?rfc include='reference.RFC.6775.xml'?>
	<?rfc include='reference.RFC.8174.xml'?>
	<?rfc include='reference.RFC.8505.xml'?>

        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2464.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4291.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4861.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4944.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6282.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7136.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6550.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6775.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8505.xml"/>

        <reference anchor="IEEE_1901.1" target="https://ieeexplore.ieee.org/document/8360785">
          <front>
	    <title>
            <title>IEEE Standard for Medium Frequency (less than 15
            12 MHz) Power Line Communications for Smart Grid Applications
            </title>
            <author>
	    <organization> IEEE-SA Standards Board </organization>
              <organization>IEEE</organization>
            </author>
            <date month="May" year="2018"/>
          </front>
	  <seriesInfo name="IEEE" name="DOI" value="10.1109/IEEESTD.2018.8360785"/>
          <seriesInfo name="IEEE Std" value="1901.1"/>
        </reference>
      </references>

<references title="Informative References">
      <references>
        <name>Informative References</name>

        <reference anchor="IEEE_1901.2a"
	target="https://standards.ieee.org/findstds/standard/1901.2a-2015.html"> target="https://ieeexplore.ieee.org/document/7286946">
          <front>
	    <title> IEEE
            <title>IEEE Standard for Low-Frequency (less than 500 kHz)
		    Narrowband Power Line Communications for Smart Grid
		    Applications - Amendment 1
            </title>
            <author>
	    <organization>IEEE-SA Standards Board</organization>
              <organization>IEEE</organization>
            </author>
            <date month="September" month="October" year="2015"/>
          </front>
	  <seriesInfo name="IEEE" name="DOI" value="10.1109/IEEESTD.2013.6679210"/>
          <seriesInfo name="IEEE Std" value="1901.2a"/>
        </reference>

	<?rfc include='reference.RFC.8415.xml'?>
	<?rfc include='reference.RFC.3972.xml'?>

        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8415.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3972.xml"/>

        <reference anchor="EUI-64"
	target="https://standards.ieee.org/content/dam/ieee-standards/standards/web/documents/tutorials/eui.pdf"> target="https://standards.ieee.org/wp-content/uploads/import/documents/tutorials/eui.pdf">
          <front>
            <title> Guidelines for 64-bit Global Use of Extended
             Unique Idenfier (EUI), Organizationally Unique Identifier (EUI-64) Registration Authority (OUI),
             and Company ID (CID)
            </title>
            <author>
	    <organization>IEEE-SA
              <organization>IEEE Standards Board</organization> Association</organization>
            </author>
            <date month="March" year="1997"/> month="August" year="2017"/>
          </front>
        </reference>

        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8981.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4963.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5535.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7217.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7973.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8036.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8065.xml"/>

<!-- [I-D.ietf-roll-aodv-rpl] IESG state AD is watching. Changed to long
format because Anand's initials were incorrect in the output -->

<reference anchor="I-D.ietf-roll-aodv-rpl" target="https://datatracker.ietf.org/doc/html/draft-ietf-roll-aodv-rpl-15">
<front>
     <title>Supporting Asymmetric Links in Low Power Networks: AODV-RPL</title>
      <author initials="C. E." surname="Perkins" fullname="Charles E. Perkins">
         <organization>Lupin Lodge</organization>
      </author>
      <author initials="S.V.R." surname="Anand" fullname="S.V.R Anand">
         <organization>Indian Institute of Science</organization>
      </author>
      <author initials="S." surname="Anamalamudi" fullname="Satish Anamalamudi">
         <organization>SRM University-AP</organization>
      </author>
      <author initials="B." surname="Liu" fullname="Bing Liu">
         <organization>Huawei Technologies</organization>
      </author>
      <date month="September" day="30" year="2022"/>
</front>
   <seriesInfo name="IEEE" value="EUI-64"/> name="Internet-Draft" value="draft-ietf-roll-aodv-rpl-15"/>
      </reference>

	<?rfc include='reference.RFC.8981.xml'?>
	<?rfc include='reference.RFC.4963.xml'?>
	<?rfc include='reference.RFC.5535.xml'?>
	<?rfc include='reference.RFC.7217.xml'?>
    <?rfc include='reference.RFC.7973.xml'?>
	<?rfc include='reference.RFC.8036.xml'?>
	<?rfc include='reference.RFC.8065.xml'?>
	<?rfc include='reference.I-D.ietf-roll-aodv-rpl'?>
	<?rfc include='reference.I-D.ietf-6tisch-minimal-security'?>
	<?rfc include='reference.RFC.9010'?>
	<?rfc include='reference.RFC.7925.xml'?>
	<?rfc include='reference.RFC.5191.xml'?>
	<?rfc include='reference.I-D.ietf-6tisch-dtsecurity-zerotouch-join'?>
	<?rfc include='reference.I-D.ietf-emu-eap-noob'?>

<!-- [I-D.ietf-6tisch-minimal-security] Published as RFC 9031 -->

        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9031.xml"/>

        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9010.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7925.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5191.xml"/>

<!-- [I-D.ietf-6tisch-dtsecurity-zerotouch-join] IESG state Expired -->

        <xi:include href="https://datatracker.ietf.org/doc/bibxml3/draft-ietf-6tisch-dtsecurity-zerotouch-join.xml"/>

<!-- [I-D.ietf-emu-eap-noob] Published as RFC 9140  -->

        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9140.xml"/>

        <reference anchor="SCENA" target="https://ieeexplore.ieee.org/document/7467440">
          <front>
            <title> State of the Art in Power Line Communications: From the Applications to the Medium
            </title>
            <author initials="C." surname="Cano" fullname="Cristina Cano">
              <organization>IEEE JOURNAL ON SELECTED AREAS IN COMMUNICATIONS</organization>
            </author>
            <author initials="A." surname="Pittolo" fullname="Alberto Pittolo">
              <organization>IEEE JOURNAL ON SELECTED AREAS IN COMMUNICATIONS</organization>
            </author>
            <author initials="D." surname="Malone" fullname="David Malone">
              <organization>IEEE JOURNAL ON SELECTED AREAS IN COMMUNICATIONS</organization>
            </author>
            <author initials="L." surname="Lampe" fullname="Lutz Lampe">
              <organization>IEEE JOURNAL ON SELECTED AREAS IN COMMUNICATIONS</organization>
            </author>
            <author initials="A." surname="Tonello" fullname="Andrea M. Tonello">
              <organization></organization>
            </author>
            <author initials="A." surname="Dabak" fullname="Anand G. Dabak">
              <organization></organization>
            </author>
            <date month="July" year="2016"/>
          </front>
	  <seriesInfo name="DOI" value="10.1109/JSAC.2016.2566018"/>
	  <refcontent>IEEE Journal on Selected Areas in Communications, Volume 34, Issue 7</refcontent>
        </reference>
      </references>
    </references>
    <section anchor="Ack" numbered="false" toc="default">
      <name>Acknowledgements</name>
      <t>
	We gratefully acknowledge suggestions from the members of the IETF 6lo
	Working Group.  Great thanks to <contact fullname="Samita
	Chakrabarti"/> and <contact fullname="Gabriel Montenegro"/> for their
	feedback and support in connecting the IEEE and ITU-T sides.  The
	authors thank <contact fullname="Scott Mansfield"/>, <contact
	fullname="Ralph Droms"/>, and <contact fullname="Pat Kinney"/> for
	their guidance in the liaison process.  The authors wish to thank
	<contact fullname="Stefano Galli"/>, <contact fullname="Thierry
	Lys"/>, <contact fullname="Yizhou Li"/>, <contact fullname="Yuefeng
	Wu"/>, and <contact fullname="Michael Richardson"/> for their valuable
	comments and contributions.  The authors wish to thank <contact
	fullname="Carles Gomez"/> for shepherding this document. The authors
	also thank <contact fullname="Paolo Volpato"/> for delivering the
	presentation at IETF 113.  Sincere acknowledgements to the valuable
	comments from the following reviewers: <contact fullname="Dave Thaler"/>, <contact
	fullname="Dan Romascanu"/>, <contact fullname="Murray Kucherawy"/>,
	<contact fullname="Benjamin Kaduk"/>, <contact fullname="Alvaro
	Retana"/>, <contact fullname="Éric Vyncke"/>, <contact fullname="Meral
	Shirazipour"/>, <contact fullname="Roman Danyliw"/>, and <contact
	fullname="Lars Eggert"/>.
      </t>
    </section>
  </back>
</rfc>