rfc9354xml2.original.xml   rfc9354.xml 
<?xml version='1.0' encoding='utf-8'?> <?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!DOCTYPE rfc [
<!ENTITY nbsp "&#160;">
<!ENTITY zwsp "&#8203;">
<!ENTITY nbhy "&#8209;">
<!ENTITY wj "&#8288;">
]> ]>
<rfc submissionType="IETF" docName="draft-ietf-6lo-plc-12" category="std"> <rfc xmlns:xi="http://www.w3.org/2001/XInclude" submissionType="IETF" category="
<?rfc compact="yes"?> std" consensus="true" docName="draft-ietf-6lo-plc-12" number="9354" ipr="trust20
<?rfc text-list-symbols="o-*+"?> 0902" obsoletes="" updates="" xml:lang="en" sortRefs="true" symRefs="true" tocIn
<?rfc subcompact="no"?> clude="true" version="3">
<?rfc sortrefs="yes"?>
<?rfc symrefs="yes"?>
<?rfc strict="yes"?>
<?rfc toc="yes"?>
<front> <!-- xml2rfc v2v3 conversion 3.15.0 -->
<title abbrev="IPv6 over PLC"> <front>
Transmission of IPv6 Packets over PLC Networks</title>
<title abbrev="IPv6 over PLC">Transmission of IPv6 Packets over Power Line C
ommunication (PLC) Networks</title>
<seriesInfo name="RFC" value="9354"/>
<author fullname="Jianqiang Hou" initials="J." surname="Hou"> <author fullname="Jianqiang Hou" initials="J." surname="Hou">
<organization> Huawei Technologies </organization> <organization>Huawei Technologies</organization>
<address> <address>
<postal> <postal>
<street>101 Software Avenue,</street> <street>101 Software Avenue,</street>
<street>Nanjing 210012</street> <city>Nanjing</city>
<street>China</street> <code>210012</code>
</postal> <country>China</country>
<email>houjianqiang@huawei.com</email> </postal>
</address> <email>houjianqiang@huawei.com</email>
</address>
</author> </author>
<author fullname="Bing Liu" initials="B." surname="Liu"> <author fullname="Bing Liu" initials="B." surname="Liu">
<organization>Huawei Technologies</organization> <organization>Huawei Technologies</organization>
<address> <address>
<postal> <postal>
<street>No. 156 Beiqing Rd. Haidian District,</street> <extaddr>Haidian District</extaddr>
<street>Beijing 100095</street> <street>No. 156 Beiqing Rd.</street>
<street>China</street> <city>Beijing</city>
</postal> <code>100095</code>
<email>remy.liubing@huawei.com</email> <country>China</country>
</address> </postal>
<email>remy.liubing@huawei.com</email>
</address>
</author> </author>
<author fullname="Yong-Geun Hong" initials="Y-G." surname="Hong"> <author fullname="Yong-Geun Hong" initials="Y-G." surname="Hong">
<organization>Daejeon University</organization> <organization>Daejeon University</organization>
<address> <address>
<postal> <postal>
<street>62 Daehak-ro, Dong-gu</street> <extaddr>Dong-gu</extaddr>
<street>Daejeon 34520</street> <street>62 Daehak-ro</street>
<street>Korea</street> <city>Daejeon</city>
</postal> <code>34520</code>
<email>yonggeun.hong@gmail.com</email> <country>Republic of Korea</country>
</address> </postal>
<email>yonggeun.hong@gmail.com</email>
</address>
</author> </author>
<author fullname="Xiaojun Tang" initials="X." surname="Tang"> <author fullname="Xiaojun Tang" initials="X." surname="Tang">
<organization abbrev="SGEPRI"> <organization abbrev="SGEPRI">
State Grid Electric Power Research Institute</organization> State Grid Electric Power Research Institute</organization>
<address> <address>
<postal> <postal>
<street>19 Chengxin Avenue</street> <street>19 Chengxin Avenue</street>
<street>Nanjing 211106</street> <city>Nanjing</city>
<street>China</street> <code>211106</code>
</postal> <country>China</country>
<email>itc@sgepri.sgcc.com.cn</email> </postal>
</address> <email>itc@sgepri.sgcc.com.cn</email>
</address>
</author> </author>
<author fullname="Charles E. Perkins" initials="C." surname="Perkins">
<author fullname="Charles E. Perkins" initials="C.E." surname="Perkins">
<organization>Lupin Lodge</organization> <organization>Lupin Lodge</organization>
<address> <address>
<phone/> <phone/>
<email>charliep@computer.org</email> <email>charliep@computer.org</email>
<!-- uri and facsimile elements may also be added -->
</address> </address>
</author> </author>
<date year="2023" month="January" />
<area>int</area>
<workgroup>6lo</workgroup>
<date /> <keyword>6lo</keyword>
<workgroup>6Lo Working Group</workgroup> <keyword>6lowpan</keyword>
<keyword>6lo-plc</keyword>
<keyword>6loplc</keyword>
<keyword>plc</keyword>
<abstract><t> <abstract>
Power Line Communication (PLC), namely using the electric-power lines <t>
Power Line Communication (PLC), namely using electric power lines
for indoor and outdoor communications, has been widely applied to for indoor and outdoor communications, has been widely applied to
support Advanced Metering Infrastructure (AMI), especially smart support Advanced Metering Infrastructure (AMI), especially smart
meters for electricity. The existing meters for electricity. The existing electricity infrastructure
electricity infrastructure facilitates the expansion of PLC facilitates the expansion of PLC deployments due to its potential
deployments due to its potential advantages in terms of cost and convenie advantages in terms of cost and convenience. Moreover, a wide variety
nce. of accessible devices raises the potential demand of IPv6 for future
Moreover, a wide variety of accessible devices raises applications. This document describes how IPv6 packets are transported
the potential demand of IPv6 for future applications. This document over constrained PLC networks, such as those described in ITU-T G.9903,
describes how IPv6 packets are transported over constrained PLC IEEE 1901.1, and IEEE 1901.2.
networks, such as ITU-T G.9903, IEEE 1901.1 and IEEE 1901.2. </t>
</t>
</abstract> </abstract>
</front> </front>
<middle>
<middle> <section anchor="Intro" numbered="true" toc="default">
<section title="Introduction" anchor="Intro"> <name>Introduction</name>
<t> <t>
The idea of using power lines for both electricity supply and The idea of using power lines for both electricity supply and
communication can be traced back to the beginning of the last communication can be traced back to the beginning of the last century.
century. Using the existing power grid to transmit messages, Power Line Using the existing power grid to transmit messages, Power Line
Communication (PLC) is a good candidate for supporting various Communication (PLC) is a good candidate for supporting various service
service scenarios such as in houses and offices, in trains and scenarios such as in houses and offices, in trains and vehicles, in
vehicles, in smart grid and advanced metering infrastructure (AMI) <xref smart grids, and in Advanced Metering Infrastructure (AMI) <xref
target="SCENA"/>. target="SCENA" format="default"/>. The data-acquisition devices in
The data acquisition devices in these scenarios share common features suc these scenarios share common features such as fixed position, large
h quantity of nodes, low data rate, and low power consumption.</t>
as fixed position, large quantity, low data rate and low power <t>
consumption.</t>
<t>
Although PLC technology has evolved over several decades, it has not Although PLC technology has evolved over several decades, it has not
been fully adapted for IPv6-based constrained networks. been fully adapted for IPv6-based constrained networks. The
The resource-constrained IoT-related scenarios lie in the low voltage resource-constrained scenarios related to the Internet of Things (IoT)
PLC networks with most applications in the area of Advanced Metering lie in the low voltage PLC networks with most applications in the area
Infrastructure (AMI), Vehicle-to-Grid communications, in-home energy of AMI, vehicle-to-grid communications, in-home energy management, and
management, and smart street lighting. IPv6 is important for PLC smart street lighting. IPv6 is important for PLC networks, due to its
networks, due to its large address space and efficient address large address space and efficient address autoconfiguration.
auto-configuration. </t>
</t> <t>
<t>
This document provides a brief overview of PLC technologies. Some of This document provides a brief overview of PLC technologies. Some of
them have LLN (low power and lossy network) characteristics, i.e., them have LLN (Low-Power and Lossy Network) characteristics, i.e.,
limited power consumption, memory and processing resources. This document limited power consumption, memory, and processing resources. This
specifies the document specifies the transmission of IPv6 packets over those
transmission of IPv6 packets over those "constrained" PLC networks. The constrained PLC networks. The general approach is to adapt elements
general approach is to adapt elements of the 6LoWPAN (IPv6 over Low-Power of the 6LoWPAN (IPv6 over Low-Power Wireless Personal Area Network)
Wireless Personal Area Network) and 6lo (IPv6 over Networks of Resource-c and 6lo (IPv6 over Networks of Resource-constrained Nodes)
onstrained Nodes) specifications, such as those described in <xref target="RFC4944"
specifications, such as <xref target="RFC4944"/>, <xref target="RFC6282"/ format="default"/>, <xref target="RFC6282" format="default"/>, <xref
>, target="RFC6775" format="default"/>, and <xref target="RFC8505"
<xref target="RFC6775"/> and <xref target="RFC8505"/> to constrained PLC format="default"/>, to constrained PLC networks.
networks. </t>
</t> </section>
</section> <!-- end section "Introduction" --> <!-- end section "Introduction" -->
<section title="Requirements Notation and Terminology" anchor="Term">
<t>
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in
BCP14 <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:"> 6LoWPAN Backbone Router </t>
<t hangText="6LBR:"> 6LoWPAN Border Router</t>
<t hangText="6LoWPAN:"> IPv6 over Low-Power Wireless Personal Area Networ
k </t>
<t hangText="6lo:"> IPv6 over Networks of Resource-constrained Nodes </t>
<t hangText="6LR:"> 6LoWPAN Router</t>
<t hangText="AMI:"> Advanced Metering Infrastructure </t>
<t hangText="BBPLC:"> Broadband Power Line Communication </t>
<t hangText="Coordinator:"> A device capable of relaying messages</t>
<t hangText="DAD:"> Duplicate Address Detection </t>
<t hangText="IID:"> IPv6 Interface Identifier </t>
<t hangText="LLN:"> Low power and Lossy Network </t>
<t hangText="MTU:"> Maximum Transmission Unit </t>
<t hangText="NBPLC:"> Narrowband Power Line Communication </t>
<t hangText="PAN:"> Personal Area Network </t>
<t hangText="PANC:"> PAN Coordinator, a coordinator which also acts as th
e
primary controller of a PAN</t>
<t hangText="PLC:"> Power Line Communication </t>
<t hangText="PLC device:"> An entity that follows the PLC standards and
implements the protocol stack described in this draft</t>
<t hangText="RPL:"> IPv6 Routing Protocol for Low-Power
and Lossy Networks </t>
<t hangText="RA:"> Router Advertisement </t>
</list>
</t>
<texttable anchor="Term_mapping" title="Terminology Mapping between PLC
standards">
<preamble>Below is a mapping table of the terminology between
<xref target="IEEE_1901.2"/>, <xref target="IEEE_1901.1"/>, <xref targ
et="ITU-T_G.9903"/> and this document.</preamble>
<ttcol align="center">IEEE 1901.2</ttcol>
<ttcol align="center">IEEE 1901.1</ttcol>
<ttcol align="center">ITU-T G.9903</ttcol>
<ttcol 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> <section anchor="Term" numbered="true" toc="default">
<name>Requirements Notation and Terminology</name>
<t>
The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQU
IRED</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 "<bcp14>OPTIONAL</bcp14>" in this document are to
be interpreted as
described in 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:
</t>
<dl newline="false" spacing="normal">
<dt>6BBR:</dt>
<dd> 6LoWPAN Backbone Router </dd>
<dt>6LBR:</dt>
<dd> 6LoWPAN Border 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 </dd>
<dt>6LR:</dt>
<dd> 6LoWPAN Router</dd>
<dt>AMI:</dt>
<dd> Advanced Metering Infrastructure </dd>
<dt>BBPLC:</dt>
<dd> Broadband Power Line Communication </dd>
<dt>Coordinator:</dt>
<dd> A device capable of relaying messages</dd>
<dt>DAD:</dt>
<dd> Duplicate Address Detection </dd>
<dt>EUI:</dt>
<dd>Extended Unique Identifier</dd>
<dt>IID:</dt>
<dd>Interface Identifier </dd>
<dt>LLN:</dt>
<dd> Low-Power and Lossy Network </dd>
<dt>MTU:</dt>
<dd> Maximum Transmission Unit </dd>
<dt>NBPLC:</dt>
<dd> Narrowband Power Line Communication </dd>
<dt>PAN:</dt>
<dd> Personal Area Network </dd>
<dt>PANC:</dt>
<dd> PAN Coordinator, a coordinator that also acts as the
primary controller of a PAN</dd>
<dt>PLC:</dt>
<dd> Power Line Communication </dd>
<dt>PLC device:</dt>
<dd> An entity that follows the PLC standards and
implements the protocol stack described in this document</dd>
<dt>RA:</dt>
<dd> Router Advertisement </dd>
<dt>RPL:</dt>
<dd>Routing Protocol for Low-Power
and Lossy Networks </dd>
</dl>
<t keepWithNext="true">Below is a mapping table of the terminology between
<xref target="IEEE_1901.2" format="default"/>, <xref target="IEEE_1901
.1" format="default"/>, <xref target="ITU-T_G.9903" format="default"/>, and this
document.</t>
<table anchor="Term_mapping" align="center">
<name>Terminology Mapping between PLC Standards</name>
<thead>
<tr>
<th align="center">IEEE 1901.2</th>
<th align="center">IEEE 1901.1</th>
<th align="center">ITU-T G.9903</th>
<th align="center">This 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> <!-- end section "Requirements Notation and Terminology" --> <section anchor="Overview" numbered="true" toc="default">
<name>Overview of PLC</name>
<t>
<section title="Overview of PLC" anchor="Overview">
<t>
PLC technology enables convenient two-way communications for home PLC technology enables convenient two-way communications for home
users and utility companies to monitor and control electric plugged users and utility companies to monitor and control electrically connected
devices such as electricity meters and street lights. PLC can also be 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 sw used in smart home scenarios, such as the control of indoor lights and
itches. Due to the switches. Due to the large range of communication frequencies, PLC is
large range of communication frequencies, PLC is generally classified generally classified into two categories: Narrowband PLC (NBPLC) for
into two categories: Narrowband PLC (NBPLC) for automation of automation of sensors (which have a low frequency band and low power
sensors (which have a low frequency band and low power cost), and cost) and Broadband PLC (BBPLC) for home and industry networking
Broadband PLC (BBPLC) for home and industry networking applications. applications.
</t> </t>
<t>
Various standards have been addressed on the MAC and PHY layers for <t>
this communication technology, e.g., BBPLC (1.8-250 MHz) including Various standards have been addressed on the
IEEE 1901 and ITU-T G.hn, and NBPLC (3-500 kHz) including ITU-T G.9902 Media Access Control (MAC) and Physical (PHY) layers. For example, standa
(G.hnem), ITU-T G.9903 (G3-PLC) <xref target="ITU-T_G.9903"/>, rds for BBPLC (1.8-250
ITU-T G.9904 (PRIME), IEEE 1901.2 <xref target="IEEE_1901.2"/> MHz) include IEEE 1901 and ITU-T G.hn, and standards for
(a combination of G3-PLC and PRIME PLC) and IEEE 1901.2a NBPLC (3-500 kHz) include ITU-T G.9902 (G.hnem), ITU-T G.9903
<xref target="IEEE_1901.2a"/> (an amendment to IEEE 1901.2). (G3-PLC) <xref target="ITU-T_G.9903" format="default"/>, ITU-T G.9904
</t> (PRIME), IEEE 1901.2 (a
<t> combination of G3-PLC and PRIME PLC) <xref target="IEEE_1901.2" format="d
A new PLC standard IEEE 1901.1 <xref efault"/>, and IEEE 1901.2a (an amendment to IEEE
target="IEEE_1901.1"/>, which is aimed at the medium frequency band of le 1901.2) <xref target="IEEE_1901.2a" format="default"/>.
ss </t>
than 12 MHz, has been published by the IEEE standard for Smart Grid <t>
IEEE 1901.1 <xref target="IEEE_1901.1" format="default"/>, a PLC standard
that is aimed at the medium frequency band of less
than 12 MHz, was published by the IEEE standard for Smart Grid
Powerline Communication Working Group (SGPLC WG). IEEE 1901.1 balances Powerline Communication Working Group (SGPLC WG). IEEE 1901.1 balances
the needs for bandwidth versus communication range, and is thus a the needs for bandwidth versus communication range and is thus a
promising option for 6lo applications. promising option for 6lo applications.
</t> </t>
<t> <t>
This specification is focused on IEEE 1901.1, IEEE 1901.2, and ITU-T G.99 03. This specification is focused on IEEE 1901.1, IEEE 1901.2, and ITU-T G.99 03.
</t> </t>
<section anchor="stack" numbered="true" toc="default">
<section title="Protocol Stack" anchor="stack"> <name>Protocol Stack</name>
<t> <t>
The protocol stack for IPv6 over PLC is illustrated in The protocol stack for IPv6 over PLC is illustrated in <xref
<xref target="fig-stack"/>. The PLC MAC/PHY layer corresponds to target="fig-stack" format="default"/>. The PLC MAC and PLC PHY layers
IEEE 1901.1, IEEE 1901.2 or ITU-T G.9903. The 6lo adaptation layer for correspond to the layers described in IEEE 1901.1, IEEE 1901.2, or ITU-T
PLC is illustrated in <xref target="v6overPLC"/>. For multihop tree G.9903. The 6lo
and mesh topologies, a routing protocol is likely to be necessary. adaptation layer for PLC is illustrated in <xref target="v6overPLC"
The routes can be built in mesh-under mode at layer 2 or in format="default"/>. For multihop tree and mesh topologies, a routing
route-over mode at layer-3, as explained in <xref target="Routing"/>. </t protocol is likely to be necessary. The routes can be built in
> mesh-under mode at Layer 2 or in route-over mode at Layer 3, as
explained in Sections <xref target="Routing" format="counter"/> and <xref
target="nd" format="counter"/>. </t>
<figure title="PLC Protocol Stack" anchor="fig-stack"> <figure anchor="fig-stack">
<artwork><![CDATA[ <name>PLC Protocol Stack</name>
<artwork name="" type="" align="left" alt=""><![CDATA[
+----------------------------------------+ +----------------------------------------+
| Application Layer | | Application Layer |
+----------------------------------------+ +----------------------------------------+
| Transport Layer | | Transport Layer |
+----------------------------------------+ +----------------------------------------+
| | | |
| IPv6 | | IPv6 Layer |
| | | |
+----------------------------------------+ +----------------------------------------+
| Adaptation layer for IPv6 over PLC | | Adaptation Layer for IPv6 over PLC |
+----------------------------------------+ +----------------------------------------+
| PLC MAC Layer | | PLC MAC Layer |
+----------------------------------------+ +----------------------------------------+
| PLC PHY Layer | | PLC PHY Layer |
+----------------------------------------+ +----------------------------------------+
]]></artwork> ]]></artwork>
</figure> </figure>
</section> <!-- end section "Protocol Stack" --> </section>
<!-- end section "Protocol Stack" -->
<section title="Addressing Modes" anchor="Addressing"> <section anchor="Addressing" numbered="true" toc="default">
<t> <name>Addressing Modes</name>
Each PLC device has a globally unique long address of 48-bits <t>
(<xref target="IEEE_1901.1"/>) or 64-bits (<xref target="IEEE_1901.2"/>, Each PLC device has a globally unique long address of 48 bits <xref
<xref target="ITU-T_G.9903"/>) and a short address of 12-bits target="IEEE_1901.1" format="default"/> or 64 bits <xref
(<xref target="IEEE_1901.1"/>) or 16-bits (<xref target="IEEE_1901.2"/>, target="IEEE_1901.2" format="default"/> <xref target="ITU-T_G.9903"
<xref target="ITU-T_G.9903"/>). The long address is set by format="default"/> and a short address of 12 bits <xref
the manufacturer according to the IEEE EUI-48 MAC address or the target="IEEE_1901.1" format="default"/> or 16 bits <xref
IEEE EUI-64 address. Each PLC device joins the network by using the target="IEEE_1901.2" format="default"/> <xref target="ITU-T_G.9903"
long address and communicates with other devices by using the format="default"/>. The long address is set by the manufacturer
short address after joining the network. Short addresses can be assigned according to the IEEE EUI-48 MAC address
during the onboarding process, by the PANC or the JRC (join registrar/coo or the IEEE EUI-64 address. Each PLC device joins the network by
rdinator) using the long address and communicates with other devices by using
in CoJP (Constrained Join Protocol) <xref target="I-D.ietf-6tisch-minimal the short address after joining the network. Short addresses can be
-security"/>. assigned during the onboarding process, by the PANC or the JRC (join
</t> registrar/coordinator) in CoJP (Constrained Join Protocol) <xref
</section> <!-- end section "Addressing Modes" --> target="RFC9031" format="default"/>.
</t>
</section>
<!-- end section "Addressing Modes" -->
<section title="Maximum Transmission Unit" anchor="mtu"> <section anchor="mtu" numbered="true" toc="default">
<t> <name>Maximum Transmission Unit</name>
<t>
The Maximum Transmission Unit (MTU) of the MAC layer determines whether The Maximum Transmission Unit (MTU) of the MAC layer determines whether
fragmentation and reassembly are needed at the adaptation layer of fragmentation and reassembly are needed at the adaptation layer of
IPv6 over PLC. IPv6 requires an MTU of 1280 octets or greater; thus IPv6 over PLC. IPv6 requires an MTU of 1280 octets or greater; thus,
for a MAC layer with MTU lower than this limit, for a MAC layer with an MTU lower than this limit,
fragmentation and reassembly at the adaptation layer are required. fragmentation and reassembly at the adaptation layer are required.
</t> </t>
<t> <t>
The IEEE 1901.1 MAC supports upper layer packets up to 2031 octets. The IEEE 1901.1 MAC supports upper-layer packets up to 2031 octets.
The IEEE 1901.2 MAC layer supports an MTU of 1576 octets (the original 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"/>). value of 1280 bytes was updated in 2015 <xref target="IEEE_1901.2a"
Though these two technologies can support IPv6 originally without fragmen format="default"/>). Though these two technologies can support
tation IPv6 originally without fragmentation and reassembly, it is possible
and reassembly, it is possible to configure a smaller MTU in high-noise c to configure a smaller MTU in a high-noise communication environment.
ommunication environment. Thus, the 6lo functions, including header compression, fragmentation,
Thus the 6lo functions, including header compression, fragmentation and r and reassembly, are still applicable and useful.
eassembly, are still applicable and useful. </t>
</t> <t>
<t> The MTU for ITU-T G.9903 is 400 octets, which is insufficient for
The MTU for ITU-T G.9903 is 400 octets, insufficient for supporting supporting IPv6's MTU. For this reason, fragmentation and reassembly
IPv6's MTU. For this reason, fragmentation and reassembly is required fo are required for G.9903-based networks to carry IPv6.
r G.9903-based networks to carry IPv6. </t>
</t> </section>
</section> <!-- end section "Maximum Transmission Unit" --> <!-- end section "Maximum Transmission Unit" -->
<section title="Routing Protocol" anchor="Routing"> <section anchor="Routing" numbered="true" toc="default">
<t> <name>Routing Protocol</name>
<t>
Routing protocols suitable for use in PLC networks include: Routing protocols suitable for use in PLC networks include:
<list style="symbols"> </t>
<t> RPL (Routing Protocol for Low-Power and Lossy Networks) <ul spacing="normal">
<xref target="RFC6550"/> is a layer-3 routing protocol. <li>RPL (Routing Protocol for Low-Power and Lossy Networks) <xref
AODV-RPL <xref target="I-D.ietf-roll-aodv-rpl"/> updates RPL to target="RFC6550" format="default"/> is a Layer 3 routing protocol.
include reactive, point-to-point, and asymmetric routing. AODV-RPL <xref target="I-D.ietf-roll-aodv-rpl" format="default"/>
IEEE 1901.2 specifies Information Elements (IEs) with MAC layer updates RPL to include reactive, point-to-point, and asymmetric
metrics, which can be provided to L3 routing protocol for parent routing. IEEE 1901.2 specifies Information Elements (IEs) with MAC
selection. layer metrics, which can be provided to a Layer 3 routing protocol for
</t> parent selection.</li>
<t> IEEE 1901.1 supports the mesh-under routing scheme. Each PLC node ma <li>IEEE 1901.1 supports the mesh-under routing scheme. Each PLC
intains a node maintains a routing table, in which each route entry comprises
routing table, in which each route entry comprises the short the short addresses of the destination and the related next hop.
addresses of the destination and the related next hop. The route entries are built during the network establishment via a
The route entries are built during the network pair of association request/confirmation messages. The route
establishment via a pair of association request/confirmation entries can be changed via a pair of proxy change
messages. The route entries can be changed via a pair of proxy request/confirmation messages. These association and proxy change
change request/confirmation messages. These association and proxy messages must be approved by the central coordinator (PANC in this
change messages must be approved by the central coordinator (PANC in document).
this document). </li>
</t> <li>LOADng (Lightweight On-demand Ad hoc Distance vector
<t> LOADng (The Lightweight On-demand Ad hoc Distance vector routing routing protocol, Next Generation) is a reactive protocol operating
protocol, Next Generation) is a reactive protocol operating at layer-2 o at Layer 2 or Layer 3. Currently, LOADng is supported in ITU-T
r layer-3. G.9903 <xref target="ITU-T_G.9903" format="default"/>, and the IEEE
Currently, LOADng is supported in ITU-T G.9903 <xref 1901.2 standard refers to ITU-T G.9903 for LOAD-based networks.
target="ITU-T_G.9903"/>, and the IEEE 1901.2 standard ref </li>
ers to </ul>
ITU-T G.9903 for LOAD-based networks. </section>
</t> <!-- end section "Routing Protocol" -->
</list> </section>
</t> <!-- end section "Overview of PLC" -->
</section> <!-- end section "Routing Protocol" -->
</section> <!-- end section "Overview of PLC" -->
<section title="IPv6 over PLC" anchor="v6overPLC"> <section anchor="v6overPLC" numbered="true" toc="default">
<t> <name>IPv6 over PLC</name>
A PLC node distinguishes between an IPv6 PDU and a non-IPv6 PDU based on the <t>
equivalent of A PLC node distinguishes between an IPv6 PDU and a non-IPv6 PDU based on
a EtherType in a layer-2 PLC PDU. <xref target="RFC7973"/> defines a Etherty the equivalent of an Ethertype in a Layer 2 PLC PDU. <xref target="RFC7973"
pe of "A0ED" for LoWPAN encapsulation, format="default"/> defines an Ethertype of "A0ED" for LoWPAN encapsulation,
and this information can be carried in the IE field in the MAC header of <xr and this information can be carried in the IE field in the MAC header of
ef target="IEEE_1901.2"/> or <xref target="ITU-T_G.9903"/>. <xref target="IEEE_1901.2" format="default"/> or <xref
And regarding <xref target="IEEE_1901.1"/>, the IP packet type has been defi target="ITU-T_G.9903" format="default"/>. And regarding <xref
ned with the corresponding target="IEEE_1901.1" format="default"/>, the IP packet type has been
MAC Service Data Unit (MSDU) type value 49. And the 4-bit Internet Protocol defined with the corresponding MAC Service Data Unit (MSDU) type value 49.
version number in the IP header And the 4-bit Internet Protocol version number in the IP header helps to
helps to distinguish between an IPv4 PDU and an IPv6 PDU. distinguish between an IPv4 PDU and an IPv6 PDU.
</t> </t>
<t> <t>
6LoWPAN and 6lo standards <xref target="RFC4944"/>, <xref target="RFC6282"/> 6LoWPAN and 6lo standards, as described in <xref target="RFC4944"
, <xref target="RFC6775"/>, and format="default"/>, <xref target="RFC6282" format="default"/>, <xref
<xref target="RFC8505"/> provide useful functionality including link-local target="RFC6775" format="default"/>, and <xref target="RFC8505"
IPv6 addresses, stateless address auto-configuration, neighbor discovery, format="default"/>, provide useful functionality, including link-local IPv6
addresses, stateless address autoconfiguration, neighbor discovery,
header compression, fragmentation, and reassembly. However, due to the header compression, fragmentation, and reassembly. However, due to the
different characteristics of the PLC media, the 6LoWPAN adaptation layer, different characteristics of the PLC media, the 6LoWPAN adaptation layer,
as it is, cannot perfectly fulfill the requirements of PLC environments. as it is, cannot perfectly fulfill the requirements of PLC
These considerations environments. These considerations suggest the need for a dedicated
suggest the need for a dedicated adaptation layer for PLC, which is adaptation layer for PLC, which is detailed in the following
detailed in the following subsections.</t> subsections.</t>
<section anchor="slaac" numbered="true" toc="default">
<section title="Stateless Address Autoconfiguration" anchor="slaac"> <name>Stateless Address Autoconfiguration</name>
<t> <t>
To obtain an IPv6 Interface Identifier (IID), a PLC device performs To obtain an IPv6 Interface Identifier (IID), a PLC device performs
stateless address autoconfiguration <xref target="RFC4944"/>. stateless address autoconfiguration <xref target="RFC4944"
The autoconfiguration can be based on either a long or short format="default"/>. The autoconfiguration can be based on either a
link-layer address. long or short link-layer address.
</t> </t>
<t> <t>
The IID can be based on the device's 48-bit MAC address or its EUI-64 The IID can be based on the device's 48-bit MAC address or its EUI-64
identifier <xref target="EUI-64"/>. A 48-bit MAC address MUST first be e identifier <xref target="EUI-64" format="default"/>. A 48-bit MAC
xtended to address <bcp14>MUST</bcp14> first be extended to a 64-bit IID
a 64-bit Interface ID by inserting 0xFFFE at the fourth and fifth by inserting 0xFFFE at the fourth and fifth octets as specified in
octets as specified in <xref target="RFC2464"/>. <xref target="RFC2464" format="default"/>. The IPv6 IID is derived
The IPv6 IID is derived from the 64-bit Interface ID by inverting from the 64-bit IID by inverting the U/L (Universal/Local)
the U/L bit <xref target="RFC4291"/>. bit <xref target="RFC4291" format="default"/>.
</t> </t>
<t> <t>
For IEEE 1901.2 and ITU-T G.9903, a 48-bit "pseudo-address" is formed 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 and the 16-bit short address as follow by the 16-bit PAN ID, 16 zero bits, and the 16-bit short address as
s: follows:
</t> </t>
<t> <list hangIndent="4" style="hanging"> <t indent="3"> 16_bit_PAN:0000:16_bit_short_address </t>
<t> 16_bit_PAN:0000:16_bit_short_address </t> <t>
</list> Then, the 64-bit IID <bcp14>MUST</bcp14> be derived by inserting the 16-b
</t> it
<t>
Then, the 64-bit Interface ID MUST be derived by inserting 16-bit
0xFFFE into as follows: 0xFFFE into as follows:
</t> </t>
<t> <list hangIndent="4" style="hanging"> <t indent="3"> 16_bit_PAN:00FF:FE00:16_bit_short_address </t>
<t> 16_bit_PAN:00FF:FE00:16_bit_short_address </t> <t>
</list>
</t>
<t>
For the 12-bit short addresses used by IEEE 1901.1, the 48-bit For the 12-bit short addresses used by IEEE 1901.1, the 48-bit
pseudo-address is formed by 24-bit NID (Network IDentifier, YYYYYY), pseudo-address is formed by a 24-bit NID (Network Identifier, YYYYYY),
12 zero bits and a 12-bit TEI (Terminal Equipment Identifier, XXX) as fol 12 zero bits, and a 12-bit TEI (Terminal Equipment Identifier, XXX) as fo
lows: llows:
<list hangIndent="4" style="hanging"> </t>
<t> YYYY:YY00:0XXX </t> <t indent="3"> YYYY:YY00:0XXX </t>
</list> <t>
The 64-bit Interface ID MUST be derived by inserting 16-bit 0xFFFE The 64-bit IID <bcp14>MUST</bcp14> be derived by inserting the 16-bit 0xF
FFE
into this 48-bit pseudo-address as follows: into this 48-bit pseudo-address as follows:
<list hangIndent="4" style="hanging"> </t>
<t> YYYY:YYFF:FE00:0XXX </t> <t indent="3"> YYYY:YYFF:FE00:0XXX </t>
</list> <t>
As investigated in <xref target="RFC7136"/>, besides <xref target="RFC429 As investigated in <xref target="RFC7136" format="default"/>, aside from
1"/>, the method discussed in
some other IID generation methods defined in IETF do not imply any semant <xref target="RFC4291" format="default"/>, other
ics IID-generation methods defined by the IETF do not imply any additional se
for the "Universal/Local" (U/L) bit (bit 6) and the Individual/Group bit mantics for the
(bit 7), Universal/Local (U/L) bit (bit 6) and the Individual/Group bit (bit
so that these two bits are not reliable indicators for their original mea 7). Therefore, these two bits are not reliable indicators. Thus, when us
nings. ing an IID derived by a short address,
Thus when using an IID derived by a short address, the operators of the P the operators of the PLC network can choose whether or not to comply with
LC the original
network can choose to comply with original meaning of these two bits or n meaning of these two bits. If they choose to
ot. comply with the original meaning, these two bits <bcp14>MUST</bcp14>
If so, since the IID derived from the short address is not global, both be set to zero, since the IID derived from the short address is not
these two bits MUST both be set to zero. In order to avoid any ambiguity global. In order to avoid any ambiguity in the derived
in the derived IID, these two bits <bcp14>MUST NOT</bcp14> be a valid part
Interface ID, these two bits MUST NOT be a valid part of the PANID of the PAN ID (for IEEE 1901.2 and ITU-T G.9903) or NID (for IEEE
(for IEEE 1901.2 and ITU-T G.9903) or NID (for IEEE 1901.1). For example, 1901.1). For example, the PAN ID or NID must always be chosen so that
the the two bits are zeros or the high six bits in PAN ID or NID are left
PANID or NID must always be chosen so that the two bits are zeros; or the shifted by two bits. If they choose not to comply with the original meani
high ng, the operator must be aware that these two
6 bits in PANID or NID are left shifted by 2 bits. If not, the operator m bits are not reliable indicators, and the IID cannot be transformed
ust back into a short link-layer address via a reverse operation of the
be aware that these two bits are not reliable indicators, mechanism presented above. However, the short address can still be
and the IID cannot be transformed back into a short link layer address vi obtained via the Unicast Address Mapping mechanism described in <xref
a a target="unicast-map" format="default"/>.
reverse operation of the mechanism presented above. However, the short ad </t>
dress can still be obtained <t>
via the Unicast Address Mapping mechanism in <xref target="unicast-map"/> For privacy reasons, the IID derived from the MAC address (with
. padding and bit clamping) <bcp14>SHOULD</bcp14> only be used for
</t> link-local address configuration. A PLC host <bcp14>SHOULD</bcp14>
<t> use the IID derived from the short link-layer address to configure
For privacy reasons, the IID derived from the MAC address (with padding a IPv6 addresses used for communication with the public network;
nd bit clamping) SHOULD only be otherwise, the host's MAC address is exposed. As per <xref
used for link-local address configuration. A PLC host SHOULD use target="RFC8065" format="default"/>, when short addresses are used on
the IID derived from the link-layer short address to configure IPv6 PLC links, a shared secret key or version number from the
addresses used for communication with the public network; otherwise, Authoritative Border Router Option <xref target="RFC6775"
the host's MAC address is exposed. As per <xref target="RFC8065"/>, when format="default"/> can be used to improve the entropy of the hash
short addresses are used on PLC links, a shared secret key or version input. Thus, the generated IID can be spread out to the full range of
number from the Authoritative Border Router Option <xref target="RFC6775" the IID address space while stateless address compression is still
/> allowed. By default, the hash algorithm
can be used to improve the entropy of the hash input, thus the generated <bcp14>SHOULD</bcp14> be SHA256, using the version number, the
IID can be spread out to the full range of the IID address space while PAN ID or NID, and the short address as the input arguments, and the
stateless address compression is still allowed. The hash algorithm by def 256-bit hash output is truncated into the IID by taking the high 64
ault of bits.
the implementations SHOULD be SHA256, using the version number, the PANID </t>
/NID </section>
and the short address as the input arguments, and the 256-bits hash outpu <!-- end section "Stateless Address Autoconfiguration" -->
t 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"> <section anchor="link-local" numbered="true" toc="default">
<t> <name>IPv6 Link-Local Address</name>
The IPv6 link-local address <xref target="RFC4291"/> for a PLC <t>
The IPv6 link-local address <xref target="RFC4291" format="default"/> for
a PLC
interface is formed by appending the IID, as defined interface is formed by appending the IID, as defined
above, to the prefix FE80::/64 (see <xref target="fig-link-local"/>). above, to the prefix FE80::/64 (see <xref target="fig-link-local" format=
</t> "default"/>).
</t>
<figure title="IPv6 Link Local Address for a PLC interface" <figure anchor="fig-link-local">
anchor="fig-link-local"> <name>IPv6 Link-Local Address for a PLC Interface</name>
<artwork><![CDATA[ <artwork name="" type="" align="left" alt=""><![CDATA[
10 bits 54 bits 64 bits 10 bits 54 bits 64 bits
+----------+-----------------------+----------------------------+ +----------+-----------------------+----------------------------+
|1111111010| (zeros) | Interface Identifier | |1111111010| (zeros) | Interface Identifier |
+----------+-----------------------+----------------------------+ +----------+-----------------------+----------------------------+
]]></artwork> ]]></artwork>
</figure> </figure>
</section> <!-- end section "IPv6 Link Local Address" --> </section>
<!-- end section "IPv6 Link Local Address" -->
<section title="Unicast Address Mapping" anchor="unicast-map"> <section anchor="unicast-map" numbered="true" toc="default">
<t> <name>Unicast Address Mapping</name>
The address resolution procedure for mapping IPv6 unicast addresses <t>
into PLC link-layer addresses follows the general description in The address-resolution procedure for mapping IPv6 unicast addresses
section 7.2 of <xref target="RFC4861"/>. <xref target="RFC6775"/> into PLC link-layer addresses follows the general description in <xref
improves this procedure by eliminating usage of multicast NS. The target="RFC4861" sectionFormat="of" section="7.2"/>. <xref
resolution is realized by the NCEs (neighbor cache entry) created target="RFC6775" format="default"/> improves this procedure by
eliminating usage of multicast NS (Neighbor Solicitation). The
resolution is realized by the NCEs (neighbor cache entries) created
during the address registration at the routers. <xref during the address registration at the routers. <xref
target="RFC8505"/> further improves the registration procedure by target="RFC8505" format="default"/> further improves the registration
enabling multiple LLNs to form an IPv6 subnet, and by inserting a procedure by enabling multiple LLNs to form an IPv6 subnet and by
link-local address registration to better serve proxy registration of inserting a link-local address registration to better serve proxy
new devices. registration of new devices.
</t> </t>
<section anchor="Unicast-1901.1" numbered="true" toc="default">
<section title="Unicast Address Mapping for IEEE 1901.1" <name>Unicast Address Mapping for IEEE 1901.1</name>
anchor="Unicast-1901.1"> <t>
<t> The Source Link-Layer Address and Target Link-Layer Address
The Source/Target Link-layer Address options for IEEE_1901.1 used options for IEEE_1901.1 used in the NS and Neighbor
in the Neighbor Solicitation and Neighbor Advertisement have the Advertisement (NA) have the following form.
following form. </t>
<figure anchor="fig-unicast-1901.1">
<figure title="Unicast Address Mapping for IEEE 1901.1" <name>Unicast Address Mapping for IEEE 1901.1</name>
anchor="fig-unicast-1901.1"> <artwork> <![CDATA[ <artwork name="" type="" align="left" alt=""><![CDATA[
0 1 2 3 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 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 : | Type | Length=1 | NID :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
:NID (continued)| Padding (all zeros) | TEI | :NID (continued)| Padding (all zeros) | TEI |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</artwork> </figure> ]]></artwork>
</t> </figure>
<t> Option fields:
<t> Option fields: </t>
<list hangIndent="6" style="hanging"> <dl newline="false" spacing="normal">
<t hangText="Type:"> 1 for Source Link-layer Address and 2 for <dt>Type:</dt>
Target Link-layer Address. </t> <dd>1 for Source Link-Layer Address and 2 for Target Link-Layer Addr
<t hangText="Length:"> The length of this option (including type ess. </dd>
and length fields) in units of 8 octets. The value of this <dt>Length:</dt>
field is 1 for the 12-bit IEEE 1901.1 PLC short addresses. </t> <dd>The length of this option (including Type and Length fields)
<t hangText="NID:"> 24-bit Network IDentifier </t> in units of 8 octets. The value of this field is 1 for the 12-bit
<t hangText="Padding:"> 12 zero bits </t> IEEE 1901.1 PLC short addresses. </dd>
<t hangText="TEI:"> 12-bit Terminal Equipment Identifier </t> <dt>NID:</dt>
</list> <dd>24-bit Network Identifier</dd>
</t> <dt>Padding:</dt>
</section> <!-- end "Unicast Address Mapping for IEEE 1901.1" --> <dd>12 zero bits </dd>
<dt>TEI:</dt>
<dd>12-bit Terminal Equipment Identifier</dd>
</dl>
</section>
<!-- end "Unicast Address Mapping for IEEE 1901.1" -->
<section <section anchor="Unicast-1901.2" numbered="true" toc="default">
title="Unicast Address Mapping for IEEE 1901.2 and ITU-T G.9903" <name>Unicast Address Mapping for IEEE 1901.2 and ITU-T G.9903</name>
anchor="Unicast-1901.2"> <t>
<t> The Source Link-Layer Address and Target Link-Layer Address options f
The Source/Target Link-layer Address options for IEEE_1901.2 and or IEEE_1901.2 and ITU-T G.9903 used in the
ITU-T G.9903 used in the Neighbor Solicitation and Neighbor NS and NA have the following form.
Advertisement have the following form. </t>
<figure title="Unicast Address Mapping for IEEE 1901.2" <figure anchor="fig-unicast-1901.2">
anchor="fig-unicast-1901.2"> <name>Unicast Address Mapping for IEEE 1901.2</name>
<artwork><![CDATA[ <artwork name="" type="" align="left" alt=""><![CDATA[
0 1 2 3 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 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 | | Type | Length=1 | PAN ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Padding (all zeros) | Short Address | | Padding (all zeros) | Short Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork> ]]></artwork>
</figure> </figure>
</t> <t>Option fields:
</t>
<t> Option fields: <dl newline="false" spacing="normal">
<list hangIndent="6" style="hanging"> <dt>Type:</dt>
<t hangText="Type:"> 1 for Source Link-layer Address and 2 for <dd>1 for Source Link-Layer Address and 2 for Target Link-Layer Addr
Target Link-layer Address. </t> ess.</dd>
<t hangText="Length:"> The length of this option (including type <dt>Length:</dt>
and length fields) in units of 8 octets. The value of this <dd>The length of this option (including Type and Length fields)
field is 1 for the 16-bit IEEE 1901.2 PLC short addresses. </t> in units of 8 octets. The value of this field is 1 for the 16-bit
<t hangText="PAN ID:"> 16-bit PAN IDentifier </t> IEEE 1901.2 PLC short addresses. </dd>
<t hangText="Padding:"> 16 zero bits </t> <dt>PAN ID:</dt>
<t hangText="Short Address:"> 16-bit short address </t> <dd>16-bit PAN IDentifier</dd>
</list> <dt>Padding:</dt>
</t> <dd>16 zero bits</dd>
</section> <!-- end "Unicast Address Mapping for IEEE 1901.2" --> <dt>Short Address:</dt>
<dd>16-bit short address</dd>
</dl>
</section>
<!-- end "Unicast Address Mapping for IEEE 1901.2" -->
</section> </section>
<section anchor="nd" numbered="true" toc="default">
<section title="Neighbor Discovery" anchor="nd"> <name>Neighbor Discovery</name>
<t> <t>
Neighbor discovery procedures for 6LoWPAN networks are described in Neighbor discovery procedures for 6LoWPAN networks are described in
Neighbor Discovery Optimization for 6LoWPANs <xref target="RFC6775"/> <xref target="RFC6775"
and <xref target="RFC8505"/>. format="default"/> and <xref target="RFC8505" format="default"/>.
These optimizations support the registration of sleeping hosts. These optimizations support the registration of sleeping hosts.
Although PLC devices are electrically powered, sleeping mode SHOULD Although PLC devices are electrically powered, sleeping mode
still be used for power saving. <bcp14>SHOULD</bcp14> still be used for power saving.
</t> </t>
<t> <t>
For IPv6 prefix dissemination, Router Solicitations (RS) and Router For IPv6 prefix dissemination, Router Solicitations (RSs) and Router
Advertisements (RA) MAY be used as per <xref target="RFC6775"/>. If the P Advertisements (RAs) <bcp14>MAY</bcp14> be used as per <xref
LC target="RFC6775" format="default"/>. If the PLC network uses
network uses route-over, the IPv6 prefix MAY be disseminated by the route-over mode, the IPv6 prefix <bcp14>MAY</bcp14> be disseminated by
layer-3 routing protocol, such as RPL, which may include the prefix in th the Layer 3 routing protocol, such as RPL, which may include the
e prefix in the DIO (DODAG Information Object) message. As per <xref
DIO (DODAG Information Object) message. As per <xref target="RFC9010"/>, target="RFC9010" format="default"/>, it is possible to have PLC
it is possible to have PLC devices configured as RPL-unaware-leaves, which do no devices configured as RPL-unaware leaves, which do not participate in
t participate in RPL at all, along with RPL-aware PLC devices. In this case, the RPL at all, along with RPL-aware PLC devices. In this case, the prefix
prefix dissemination SHOULD use the RS/RA messages. dissemination <bcp14>SHOULD</bcp14> use the RS/RA messages.
</t> </t>
<t> <t>
For context information dissemination, Router Advertisements (RA) MUST be For dissemination of context information, RAs <bcp14>MUST</bcp14> be used
used as per <xref target="RFC6775"/>. The 6LoWPAN context option (6CO) MU as per <xref target="RFC6775" format="default"/>. The 6LoWPAN context
ST option (6CO) <bcp14>MUST</bcp14> be included in the RA to disseminate
be included in the RA to disseminate the Context IDs used for prefix and/ the Context IDs used for prefix and/or address compression.
or address compression. </t>
</t> <t>
<t> For address registration in route-over mode, a PLC device
For address registration in route-over mode, a PLC device MUST <bcp14>MUST</bcp14> register its addresses by sending a unicast
register its addresses by sending a unicast link-local Neighbor link-local NS to the 6LR. If the registered address is link local, the
Solicitation to the 6LR. If the registered address is link-local, the 6LR 6LR <bcp14>SHOULD NOT</bcp14> further register it to the registrar
SHOULD NOT further register it to the registrar (6LBR, 6BBR). Otherwise, (6LBR or 6BBR). Otherwise, the address <bcp14>MUST</bcp14> be registered
the via an ARO (Address Registration Option) or EARO (Extended Address
address MUST be registered via an ARO or EARO included in the DAR (<xref Registration Option) included in the DAR (Duplicate Address Request)
target="RFC6775"/>) or EDAR (<xref target="RFC8505"/>) messages. <xref target="RFC6775" format="default"/> or EDAR (Extended Duplicate
For Address Request) <xref target="RFC8505" format="default"/>
RFC8505 compliant PLC devices, the 'R' flag in the EARO MUST be set when messages. For PLC devices compliant with <xref target="RFC8505"/>, the
sending Neighbor Solicitations in order to extract the status information 'R' flag in the EARO <bcp14>MUST</bcp14> be set when sending NSs in
in order to extract the status information in the replied NAs from the
the replied Neighbor Advertisements from the 6LR. If DHCPv6 is used to 6LR. If DHCPv6 is used to assign addresses or the IPv6 address is
assign addresses or the IPv6 address is derived from unique long or short derived from the unique long or short link-layer address, Duplicate
link layer address, Duplicate Address Detection (DAD) SHOULD NOT be utilized. Address Detection (DAD) <bcp14>SHOULD NOT</bcp14> be utilized.
Otherwise, the DAD MUST be performed at the 6LBR (as per <xref Otherwise, DAD <bcp14>MUST</bcp14> be performed at the 6LBR (as per
target="RFC6775"/>) or proxied by the routing registrar (as per < <xref target="RFC6775" format="default"/>) or proxied by the routing
xref registrar (as per <xref target="RFC8505" format="default"/>). The
target="RFC8505"/>). The registration status is fed back via the registration status is fed back via the DAC (Duplicate Address
DAC Confirmation) or EDAC (Extended Duplicate Address Confirmation)
or EDAC message from the 6LBR and the Neighbor Advertisement (NA) from th message from the 6LBR and the NA from the 6LR. <xref target="RFC8505"
e sectionFormat="of" section="6"/> shows how devices that only behave as sp
6LR. The section 6 of <xref target="RFC8505"/> how RFC6775-only devices w ecified in <xref target="RFC6775"/> can work
ork with RFC8505-updated devices. with devices that have been updated per <xref target="RFC8505"/>.
</t> </t>
<t> <t>
For address registration in mesh-under mode, since all the PLC devices ar For address registration in mesh-under mode, since all the PLC devices
e link-local neighbors to the 6LBR, DAR/DAC or EDAR/EDAC messages are not are link-local neighbors to the 6LBR, DAR/DAC or EDAR/EDAC messages
required. A PLC device MUST register its addresses by sending a unicast N are not required. A PLC device <bcp14>MUST</bcp14> register its
S addresses by sending a unicast NS message with an ARO or EARO. The
message with an ARO or EARO. The registration status is fed back via the registration status is fed back via the NA message from the 6LBR.
NA message from the 6LBR. </t>
</t> </section>
<!-- end section "Neighbor Discovery" -->
</section> <!-- end section "Neighbor Discovery" -->
<section title="Header Compression" anchor="Compression">
<t>
The compression of IPv6 datagrams within PLC MAC frames refers to
<xref target="RFC6282"/>, which updates <xref target="RFC4944"/>.
Header compression as defined in <xref target="RFC6282"/> which
specifies the compression format for IPv6 datagrams on top of
IEEE 802.15.4, is the basis for IPv6 header compression in PLC.
For situations when PLC MAC MTU cannot support the 1280-octet IPv6
packet, headers MUST be compressed according to <xref target="RFC6282"/>
encoding formats, including the Dispatch Header, the LOWPAN_IPHC and
the compression residu carried in-line.
</t>
<t>
For IEEE 1901.2 and G.9903, the IP header compression follows the
instruction in <xref target="RFC6282"/>. However, additional adaptation
MUST 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"/>,
which is illustrated as following.
</t>
<t>
SAM: Source Address Mode:
</t>
<t>
If SAC=0: Stateless compression
<list hangIndent="6" style="hanging">
<t hangText="10:"> 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, in which the first 4 bits are zero. </t>
</list>
</t>
<t>
If SAC=1: stateful context-based compression
<list hangIndent="6" style="hanging">
<t hangText="10:"> 16 bits. The address is derived using context informat
ion and the 16 bits carried in-line. Bits covered by context information are alw
ays used. Any IID bits not covered by context information are taken directly fro
m their corresponding bits in the 16-bit to IID mapping given by 0000:00ff:fe00:
0XXX, where 0XXX are the 16 bits carried in-line, in which the first 4 bits are
zero. Any remaining bits are zero. </t>
</list>
</t>
<t> <section anchor="Compression" numbered="true" toc="default">
DAM: Destination Address Mode: <name>Header Compression</name>
</t> <t>
<t> IPv6 header compression in PLC is based on <xref target="RFC6282"
If M=0 and DAC=0: Stateless compression format="default"/> (which updates <xref target="RFC4944"
<list hangIndent="6" style="hanging"> format="default"/>). <xref target="RFC6282" format="default"/> specifies
<t hangText="10:"> 16 bits. The first 112 bits of the address are elided. the compression format for IPv6 datagrams on top of IEEE 802.15.4;
The value of the first 64 bits is the link-local prefix therefore, this format is used for compression of IPv6 datagrams within
padded with zeros. The following 64 bits are 0000:00ff: PLC MAC frames. For situations when the PLC
fe00:0XXX, where 0XXX are the 16 bits carried in-line, in which the MAC MTU cannot support the 1280-octet IPv6 packet, the headers
first 4 bits are zero. </t> <bcp14>MUST</bcp14> be compressed according to the encoding formats
</list> specified in <xref target="RFC6282" format="default"/>, including the
</t> Dispatch Header, the LOWPAN_IPHC, and the compression residue carried
<t> inline.
If M=0 and DAC=1: stateful context-based compression </t>
<list hangIndent="6" style="hanging"> <t>
<t hangText="10:"> 16 bits. The address is derived using context informat For IEEE 1901.2 and ITU-T G.9903, the IP header compression follows the
ion instruction in <xref target="RFC6282" format="default"/>. However,
and the 16 bits carried in-line. Bits covered by context additional adaptation <bcp14>MUST</bcp14> be considered for IEEE
information are always used. Any IID bits not covered by 1901.1 since it has a short address of 12 bits instead of 16 bits. The
context information are taken directly from their only modification is the semantics of the "Source Address Mode" and
corresponding bits in the 16-bit to IID mapping given by the "Destination Address Mode" when set as "10" in <xref
0000:00ff:fe00:0XXX, where 0XXX are the 16 bits carried in- target="RFC6282" sectionFormat= "of" section="3.1"/>, which is
line, in which the first 4 bits are zero. Any remaining bits are ze illustrated as follows.
ro. </t> </t>
</list> <t>SAM: Source Address Mode:</t>
</t> <t>If SAC=0: Stateless compression</t>
</section> <!-- end section "Header Compression" --> <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 inline, in which the first 4 bits are zero. </dd>
</dl>
<t>If SAC=1: Stateful context-based 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 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 th
e
16-bit short address and the IID as provided by 0000:00ff:fe00:0XXX,
where 0XXX are the 16 bits
carried inline, in which the first 4 bits are zero. Any remaining
bits are zero. </dd>
</dl>
<t>DAM: Destination Address Mode:</t>
<t>If M=0 and DAC=0: Stateless 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 inline, in which the first 4 bits are zero.
</dd>
</dl>
<t>If M=0 and DAC=1: Stateful context-based 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 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 betwee
n
the 16-bit short address and the IID as provided by 0000:00ff:fe00:0XX
X,
where 0XXX are the 16 bits
carried inline, in which the first 4 bits are zero. Any remaining
bits are zero. </dd>
</dl>
</section>
<!-- end section "Header Compression" -->
<section title="Fragmentation and Reassembly" anchor="frag"> <section anchor="frag" numbered="true" toc="default">
<t> <name>Fragmentation and Reassembly</name>
The constrained PLC MAC layer provides the function of fragmentation and <t>
reassembly. The constrained PLC MAC layer provides the functions of fragmentation
However, fragmentation and reassembly is still required at the adaptation and reassembly. However, fragmentation and reassembly are still
layer, required at the adaptation layer if the MAC layer cannot support the
if the MAC layer cannot support the minimum MTU demanded by IPv6, which i minimum MTU demanded by IPv6, which is 1280 octets. </t>
s 1280 octets. </t> <t>
<t> In IEEE 1901.1 and IEEE 1901.2, the MAC layer supports payloads as big
In IEEE 1901.1 and IEEE 1901.2, the MAC layer supports payloads as 2031 octets and 1576 octets, respectively. However, when the
as big as 2031 octets and 1576 octets respectively. However, when the channel condition is noisy, smaller packets have a higher transmission
channel condition is noisy, smaller packets have higher transmission succ success rate, and the operator can choose to configure smaller MTU at
ess rate, the operator can choose to configure smaller MTU at
the MAC layer. If the configured MTU is smaller than 1280 octets, the the MAC layer. If the configured MTU is smaller than 1280 octets, the
fragmentation and reassembly defined in <xref target="RFC4944"/> MUST be fragmentation and reassembly defined in <xref target="RFC4944"
used. format="default"/> <bcp14>MUST</bcp14> be used.
</t> </t>
<t> <t>
In ITU-T G.9903, the maximum MAC payload size is fixed to 400 octets, 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, so to cope with the required MTU of 1280 octets by IPv6,
fragmentation and reassembly at the 6lo adaptation layer MUST be provided fragmentation and reassembly at the 6lo adaptation layer <bcp14>MUST</bcp
as specified in <xref target="RFC4944"/>. 14> be provided
</t> as specified in <xref target="RFC4944" format="default"/>.
<t> </t>
<xref target="RFC4944"/> uses a 16-bit datagram tag to identify the fragm <t>
ents of the same IP packet. <xref target="RFC4963"/> specifies that at high data <xref target="RFC4944" format="default"/> uses a 16-bit datagram tag
rates, the 16-bit IP identification field is not large enough to prevent freque to identify the fragments of the same IP packet. <xref
nt incorrectly assembled IP fragments. For constrained PLC, the data rate is muc target="RFC4963" format="default"/> specifies that at high data rates,
h lower than the situation mentioned in RFC4963, thus the 16-bit tag is sufficie the 16-bit IP identification field is not large enough to prevent
nt to assemble the fragments correctly. frequent incorrectly assembled IP fragments.
</t> For constrained PLC, the data rate is much lower than the situation mentioned
</section> <!-- end section "Fragmentation and Reassembly" --> in <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>
<!-- end section "IPv6 over Narrowband PLC" -->
<section title="Internet Connectivity Scenarios and Topologies" <section anchor="Topologies" numbered="true" toc="default">
anchor="Topologies"> <name>Internet Connectivity Scenarios and Topologies</name>
<t> <t>
The PLC network model can be simplified to two kinds of network device: The PLC network model can be simplified to two kinds of network devices:
PAN Coordinator (PANC) and PLC Device. The PANC is the primary coordinat PAN Coordinator (PANC) and PLC device. The PANC is the primary
or coordinator of the PLC subnet and can be seen as a primary node; PLC
of the PLC subnet and can be seen as a primary node; PLC Devices are devices are typically PLC meters and sensors. The address registration
typically PLC meters and sensors. The address registration and DAD featu and DAD features can also be deployed on the PANC, for example, the 6LBR
res <xref target="RFC6775" format="default"/> or the routing registrar
can also be deployed on the PANC, for example the 6LBR <xref target="RFC6 <xref target="RFC8505" format="default"/>. IPv6 over PLC networks are
775"/> built as tree, mesh, or star topologies according to the use cases.
or the routing registrar in <xref target="RFC8505"/>. IPv6 over PLC Generally, each PLC network has one PANC. In some cases, the PLC network
networks are built as trees, meshes or stars topology according to the us can have alternate coordinators to replace the PANC when the PANC leaves
e cases. the network for some reason. Note that the PLC topologies in this section
Generally, each PLC network has one PANC. In some cases, the PLC network are based on logical connectivity, not physical links. The term "PLC
can have alternate coordinators to replace the PANC when the PANC leaves subnet" refers to a multilink subnet, in which the PLC devices share the
the network for some reason. Note that the PLC topologies in this sectio same address prefix.
n
are based on logical connectivity, not physical links. The term "PLC subn
et"
refers to a multilink subnet, in which the PLC devices share the same add
ress prefix.
</t> </t>
<t> <t>
The star topology is common in current PLC scenarios. In single-hop The star topology is common in current PLC scenarios. In single-hop star
star topologies, topologies, communication at the link layer only takes place between a PLC
communication at the link layer only takes place between a PLC Device and device and a PANC. The PANC typically collects data (e.g., a meter
a PANC. The PANC typically collects data (e.g., a meter reading) from reading) from the PLC devices and then concentrates and uploads the data
the PLC devices, and then concentrates and uploads the data through through Ethernet or cellular networks (see <xref target="fig-plc-star"
Ethernet or Cellular networks (see <xref target="fig-plc-star"/>). The coll format="default"/>). The collected data is transmitted by the smart
ected meters through PLC, aggregated by a concentrator, and sent to the utility an
data is transmitted by the smart meters through PLC, aggregated by a d
concentrator, sent to the utility and then to a Meter Data Management then to a Meter Data Management System for data storage, analysis, and
System for data storage, analysis and billing. This topology has billing. This topology has been widely applied in the deployment of smart
been widely applied in the deployment of smart meters, especially in meters, especially in apartment buildings.
apartment buildings.
</t> </t>
<figure title="PLC Star Network connected to the Internet" <figure anchor="fig-plc-star">
anchor="fig-plc-star"> <name>PLC Star Network Connected to the Internet</name>
<artwork><![CDATA[ <artwork name="" type="" align="left" alt=""><![CDATA[
PLC Device PLC Device PLC Device PLC Device
\ / +--------- \ / +---------
\ / / \ / /
\ / + \ / +
\ / | \ / |
PLC Device ------ PANC ===========+ Internet PLC Device ------ PANC ===========+ Internet
/ \ | / \ |
/ \ + / \ +
/ \ \ / \ \
/ \ +--------- / \ +---------
PLC Device PLC Device PLC Device PLC Device
<----------------------> <---------------------->
PLC subnet (IPv6 over PLC) PLC subnet (IPv6 over PLC)
]]></artwork> ]]></artwork>
</figure> </figure>
<t> <t>
A tree topology is useful when the distance between a device A and the PANC is A tree topology is useful when the distance between a device A and the PANC is
beyond the PLC allowed limit and there is another device B in between beyond the 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 able to communicate with both sides. Device B in this case acts as both
a PLC Device and a Coordinator. a PLC device and a Coordinator.
For this scenario, the link layer For this scenario, the link-layer
communications take place between device A and device B, and between communications take place between device A and device B, and between
device B and PANC. An example of a PLC tree network is depicted device B and PANC. An example of a PLC tree network is depicted
in <xref target="fig-plc-tree"/>. This topology can be applied in in <xref target="fig-plc-tree" format="default"/>. This topology can be app lied in
smart street lighting, where the lights adjust the brightness to reduce smart street lighting, where the lights adjust the brightness to reduce
energy consumption while sensors are deployed on the street-lights to energy consumption while sensors are deployed on the street lights to
provide information such as light intensity, temperature, and humidity. provide information such as light intensity, temperature, and humidity.
The data transmission distance in the street lighting scenario is normally The data-transmission distance in the street lighting scenario is normally
above several kilometers, thus a PLC tree network is required. A more above several kilometers; thus, a PLC tree network is required. A more
sophisticated AMI network may also be constructed into the tree topology sophisticated AMI network may also be constructed into the tree topology
which is depicted in <xref target="RFC8036"/>. A tree topology is suitable that is depicted in <xref target="RFC8036" format="default"/>. A tree topol ogy is suitable
for AMI scenarios that require large coverage but low density, for AMI scenarios that require large coverage but low density,
e.g., the deployment of smart meters in rural areas. RPL is suitable 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 for maintenance of a tree topology in which there is no need for
communication directly between PAN devices. communication directly between PAN devices.
</t> </t>
<figure title="PLC Tree Network connected to the Internet" <figure anchor="fig-plc-tree">
anchor="fig-plc-tree"> <name>PLC Tree Network Connected to the Internet</name>
<artwork><![CDATA[ <artwork name="" type="" align="left" alt=""><![CDATA[
PLC Device PLC Device
\ +--------- \ +---------
PLC Device A \ / PLC Device A \ /
\ \ + \ \ +
\ \ | \ \ |
PLC Device B -- PANC ===========+ Internet PLC Device B -- PANC ===========+ Internet
/ / | / / |
/ / + / / +
PLC Device---PLC Device / \ PLC Device---PLC Device / \
/ +--------- / +---------
PLC Device---PLC Device PLC Device---PLC Device
<-------------------------> <------------------------->
PLC subnet (IPv6 over PLC) PLC subnet (IPv6 over PLC)
]]></artwork> ]]></artwork>
</figure> </figure>
<t>
Mesh networking in PLC is of great potential applications and has been <t>
Mesh networking in PLC has many potential applications and has been
studied for several years. By connecting all nodes with their neighbors studied for several years. By connecting all nodes with their neighbors
in communication range (see <xref target="fig-plc-mesh"/>), a mesh in communication range (see <xref target="fig-plc-mesh" format="default"/>), a mesh
topology dramatically enhances the communication efficiency and thus topology dramatically enhances the communication efficiency and thus
expands the size of PLC networks. A simple use case is the smart home 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 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 tar the state of home lights (ON/OFF) and doors (OPEN/CLOSE). AODV-RPL <xref targ
get="I-D.ietf-roll-aodv-rpl"/>) et="I-D.ietf-roll-aodv-rpl" format="default"/>
enables direct PLC device to PLC device communication, without being obliged enables direct communication between PLC devices, without being obliged
to transmit frames through the PANC, which is a requirement often cited to transmit frames through the PANC, which is a requirement often cited
for AMI infrastructure. for the AMI infrastructure.
</t> </t>
<figure anchor="fig-plc-mesh">
<figure title="PLC Mesh Network connected to the Internet" <name>PLC Mesh Network Connected to the Internet</name>
anchor="fig-plc-mesh"> <artwork name="" type="" align="left" alt=""><![CDATA[
<artwork><![CDATA[
PLC Device---PLC Device PLC Device---PLC Device
/ \ / \ +--------- / \ / \ +---------
/ \ / \ / / \ / \ /
/ \ / \ + / \ / \ +
/ \ / \ | / \ / \ |
PLC Device--PLC Device---PANC ===========+ Internet PLC Device--PLC Device---PANC ===========+ Internet
\ / \ / | \ / \ / |
\ / \ / + \ / \ / +
\ / \ / \ \ / \ / \
\ / \ / +--------- \ / \ / +---------
PLC Device---PLC Device PLC Device---PLC Device
<-------------------------------> <------------------------------->
PLC subnet (IPv6 over PLC) PLC subnet (IPv6 over PLC)
]]></artwork> ]]></artwork>
</figure> </figure>
</section> </section>
<section anchor="OAM" numbered="true" toc="default">
<section title="Operations and Manageability Considerations" anchor="OAM"> <name>Operations and Manageability Considerations</name>
<t> <t>
The constrained PLC networks are not managed in the same way as an enterp Constrained PLC networks are not managed in the same way as
rise enterprise networks or carrier networks. Constrained PLC networks,
network or a carrier network. Constrained PLC networks, like the other Io like the other IoT networks, are designed to be self-organized and
T networks, self-managed. The software or firmware is flashed into the devices
are designed to be self-organized and self-managed. The software or firmw before deployment by the vendor or operator. And during the deployment
are is process, the devices are bootstrapped, and no extra configuration is
flashed into the devices before deployment by the vendor or operator. And needed to get the devices connected to each other. Once a device
during becomes offline, it goes back to the bootstrapping stage and tries to
the deployment process, the devices are bootstrapped, and no extra config rejoin the network. The onboarding status of the devices and the
uration topology of the PLC network can be visualized via the PANC. The
is needed to get the devices connected to each other. Once a device becom recently formed IOTOPS WG in the IETF aims to identify the
es offline, requirements in IoT network management, and operational practices will
it goes back to the bootstrapping stage and tries to rejoin the network. be published. Developers and operators of PLC networks should be able
The onboarding to learn operational experiences from this WG.
status of the devices and the topology of the PLC network can be visualiz </t>
ed via the </section>
PANC. The recently-formed iotops WG in IETF is aiming to identify the req <section anchor="IANA" numbered="true" toc="default">
uirements in <name>IANA Considerations</name>
IoT network management, and operational practices will be published. Deve <t>
lopers and This document has no IANA actions.
operators of PLC networks should be able to learn operational experiences </t>
from this WG. </section>
</t> <section anchor="Security" numbered="true" toc="default">
</section> <name>Security Considerations</name>
<section title="IANA Considerations" anchor="IANA"> <t>
<t>
There are no IANA considerations related to this document.
</t>
</section>
<section title="Security Considerations" anchor="Security">
<t>
Due to the high accessibility of power grids, PLC might be susceptible Due to the high accessibility of power grids, PLC might be susceptible
to eavesdropping within its communication coverage, e.g., one to eavesdropping within its communication coverage, e.g., one
apartment tenant may have the chance to monitor the other smart apartment tenant may have the chance to monitor the other smart
meters in the same apartment building. Link layer security mechanisms, meters in the same apartment building. Link-layer security mechanisms,
such as payload encryption and devcie authentication, such as payload encryption and device authentication,
are designed in the PLC technologies mentioned in this document. are designed in the PLC technologies mentioned in this document.
Additionally, on-path malicious PLC device could eavesdrop or modify Additionally, an on-path malicious PLC device could eavesdrop or modify
packets sent through it if appropriate confidentiality and integrity packets sent through it if appropriate confidentiality and integrity
mechanisms are not implemented. mechanisms are not implemented.
</t> </t>
<t>
Malicious PLC devices could paralyze the whole network via DOS attacks, <t>
e.g., keep joining and leaving the network frequently, or sending multica Malicious PLC devices could paralyze the whole network via DoS
st routing attacks, e.g., keep joining and leaving the network frequently or
messages containing fake metrics. A device may also inadvertently join a sending multicast routing messages containing fake metrics. A device
wrong or even may also inadvertently join a wrong or even malicious network,
malicious network, exposing its data to malicious users. When communicati exposing its data to malicious users. When communicating with a device
ng with a outside the PLC network, the traffic has to go through the PANC. Thus,
device outside the PLC network, the traffic has to go through the PANC. T the PANC must be a trusted entity. Moreover, the PLC network must
hus the PANC prevent malicious devices from joining the network. Thus, mutual
must be a trusted entity. Moreover, the PLC network must prevent malicio authentication of a PLC network and a new device is important, and it
us can be conducted during the onboarding process of the new
devices to join in the network. Thus Mutual device. Methods include protocols such as the TLS/DTLS Profile <xref targ
authentication of a PLC network and a new device is important, and it can et="RFC7925"
be conducted during the format="default"/> (exchanging pre-installed certificates over DTLS),
onboarding process of the new device. Methods include protocols such as the Constrained Join Protocol (CoJP) <xref target="RFC9031" format="defau
<xref target="RFC7925"/> (exchanging pre-installed certificates over DTLS lt"/> (which uses pre-shared
), keys), and Zero-Touch Secure Join <xref target="I-D.ietf-6tisch-dtsecurit
<xref target="I-D.ietf-6tisch-minimal-security"/> (which uses pre-shared y-zerotouch-join"
keys), and <xref target="I-D.ietf-6tisch-dtsecurity-zerotouch-join"/> format="default"/> (an IoT version of the Bootstrapping Remote Secure Key
(a IoT version of BRSKI, which uses IDevID and MASA service to facilitate Infrastructure (BRSKI), which uses an Initial
authentication). It is also possible to use EAP Device Identifier (IDevID) and a Manufacturer Authorized Signing
methods such as <xref target="I-D.ietf-emu-eap-noob"/> via transports lik Authority (MASA) service to facilitate authentication). It is also
e possible to use Extensible Authentication Protocol (EAP) methods such
PANA <xref target="RFC5191"/>. No specific mechanism is specified by this as the one defined in <xref target="RFC9140" format="default"/> via trans
document, as an appropriate mechanism will depend upon deployment ports like
circumstances. In some cases, the PLC devices can be deployed in uncontro Protocol for Carrying Authentication for Network Access (PANA) <xref
lled places, target="RFC5191" format="default"/>. No specific mechanism is
where the devices may be accessed physically and be compromised via key e specified by this document, as an appropriate mechanism will depend
xtraction. Since upon deployment circumstances. In some cases, the PLC devices can be
the compromised device may be still able to join in the network since its deployed in uncontrolled places, where the devices may be accessed
credentials are still valid. When group-shared physically and be compromised via key extraction. The compromised
symmetric keys are used in the network, the consequence is even more seve device may be still able to join in the network since its credentials
re, i.e., the whole network are still valid. When group-shared symmetric keys are used in the
or a large part of the network is at risk. Thus in scenarios where the p network, the consequence is even more severe, i.e., the whole network
hysical attacks is considered to be relatively highly possible, or a large part of the network is at risk. Thus, in scenarios where
per device credentials SHOULD be used. Moreover, additional end-to-end se physical attacks are considered to be relatively highly possible,
curity services" per-device credentials <bcp14>SHOULD</bcp14> be used. Moreover,
is a complementary to the network side security mechanisms, e.g., if a de additional end-to-end security services are complementary to the
vices is compromised and network-side security mechanisms, e.g., if a device is compromised and
it has joined in the network, and then it claims itself as the PANC and has joined in the network, and then it claims itself as the PANC and
try to make the rest devices join its network. In this situation, the re tries to make the rest of the devices join its network. In this
al PANC can send an alarm to the operator to acknowledge the risk. situation, the real PANC can send an alarm to the operator to
Other behavior analysis mechanisms can be deployed to recoginize the mali acknowledge the risk. Other behavior-analysis mechanisms can be
cious PLC devices by inspecting the packets and the data. deployed to recognize the malicious PLC devices by inspecting the
</t> packets and the data.
<t> </t>
<t>
IP addresses may be used to track devices on the Internet; such IP addresses may be used to track devices on the Internet; such
devices can often in turn be linked to individuals and their activities. devices can often in turn be linked to individuals and their
Depending on the application and the actual use pattern, this may be activities. Depending on the application and the actual use pattern,
undesirable. To impede tracking, globally unique and non-changing this may be undesirable. To impede tracking, globally unique and
characteristics of IP addresses should be avoided, e.g., by non-changing characteristics of IP addresses should be avoided, e.g.,
frequently changing the global prefix and avoiding unique link-layer by frequently changing the global prefix and avoiding unique
derived IIDs in addresses. <xref target="RFC8065"/> discusses the privac link-layer derived IIDs in addresses. <xref target="RFC8065"
y format="default"/> discusses the privacy threats when an IID is generated
threats when interface identifiers (IID) are generated without sufficient without sufficient entropy, including
entropy, correlation of activities over time, location tracking,
including correlation of activities over time, location tracking, device-specific vulnerability exploitation, and address scanning. And
device-specific vulnerability exploitation, and address scanning. And an an effective way to deal with these threats is to have enough entropy
effective way to in the IID compared to the link lifetime. Consider a PLC network
deal with these threats is to have enough entropy in the IID compairing t with 1024 devices and a link lifetime is 8 years, according to
o the link lifetime. the formula in <xref target="RFC8065" format="default"/>, an entropy
Consider a PLC network with 1024 devices and its link lifetime is 8 years 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
according to the formula in RFC8065, an entropy of 40 bits is sufficient. may be vulnerable to deal with address scans. Thus, as suggested in
Padding the short address (12 or 16 bits) to generate the IID of a routab <xref target="slaac"/>, a hash function can be used to generate a 64-bit
le IID. When the version number of the PLC network is changed, the
IPv6 address in the public network may be vulnerable to deal with address IPv6 addresses can be changed as well. Other schemes such as limited
scans. lease period in DHCPv6 <xref target="RFC8415" format="default"/>,
Thus as suggest in the section 4.1, a hash function can be used to genera Cryptographically Generated Addresses (CGAs) <xref target="RFC3972"
te a 64 bits IID. format="default"/>, Temporary Address Extensions <xref
When the version number of the PLC network is changed, the IPv6 addresses target="RFC8981" format="default"/>, Hash-Based Addresses (HBAs) <xref
can be changed as well. target="RFC5535" format="default"/>, or semantically opaque addresses
Other schemes such as limited lease period in DHCPv6 <xref target="RFC841 <xref target="RFC7217" format="default"/> <bcp14>SHOULD</bcp14> be
5"/>, used to enhance the IID privacy.
Cryptographically Generated Addresses (CGAs) <xref target="RFC3972"/>, </t>
Temporary Address Extensions <xref target="RFC8981"/>, Hash-Based </section>
Addresses (HBAs) <xref target="RFC5535"/>, or semantically opaque </middle>
addresses <xref target="RFC7217"/> SHOULD be used to enhance the IID priv <back>
acy.
</t>
</section>
<section title="Acknowledgements" anchor="Ack"> <displayreference target="I-D.ietf-roll-aodv-rpl" to="AODV-RPL"/>
<t> <displayreference target="I-D.ietf-6tisch-dtsecurity-zerotouch-join" to="ZEROTOU
<!-- CEP: Was it intended to specifically acknowledge the 6LoWPAN working CH"/>
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 contri
butions.
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 Tha
ler, Dan Romascanu,
Murray Kucherawy, Benjamin Kaduk, Alvaro Retana, Éric Vyncke, Meral Shira
zipour, Roman Danyliw and Lars Eggert.
</t>
</section>
</middle> <references>
<name>References</name>
<references>
<name>Normative References</name>
<reference anchor="IEEE_1901.2" target="https://ieeexplore.ieee.org/docu
ment/6679210">
<front>
<title> IEEE Standard for Low-Frequency (less than 500 kHz)
Narrowband Power Line Communications for Smart Grid
Applications
</title>
<author>
<organization>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"/>
</reference>
<back> <reference anchor="ITU-T_G.9903" target="https://www.itu.int/rec/T-REC-G
<references title="Normative References"> .9903">
<front>
<title>Narrowband orthogonal frequency division
multiplexing power line communication transceivers for G3-PLC
networks
</title>
<author>
<organization>ITU-T</organization>
</author>
<date month="August" year="2017"/>
</front>
<seriesInfo name="ITU-T Recommendation" value="G.9903"/>
</reference>
<reference anchor="IEEE_1901.2" <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2
target="https://standards.ieee.org/findstds/standard/1901.2-2013.html"> 119.xml"/>
<front> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2
<title> IEEE Standard for Low-Frequency (less than 500 kHz) 464.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4
291.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4
861.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4
944.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6
282.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7
136.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6
550.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6
775.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
174.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
505.xml"/>
<reference anchor="IEEE_1901.1" target="https://ieeexplore.ieee.org/docu
ment/8360785">
<front>
<title>IEEE Standard for Medium Frequency (less than
12 MHz) Power Line Communications for Smart Grid Applications
</title>
<author>
<organization>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"/>
</reference>
</references>
<references>
<name>Informative References</name>
<reference anchor="IEEE_1901.2a" target="https://ieeexplore.ieee.org/doc
ument/7286946">
<front>
<title>IEEE Standard for Low-Frequency (less than 500 kHz)
Narrowband Power Line Communications for Smart Grid Narrowband Power Line Communications for Smart Grid
Applications Applications - Amendment 1
</title> </title>
<author> <author>
<organization> IEEE-SA Standards Board </organization> <organization>IEEE</organization>
</author> </author>
<date month="October" year="2013"/> <date month="October" year="2015"/>
</front> </front>
<seriesInfo name="IEEE" value="1901.2"/> <seriesInfo name="DOI" value="10.1109/IEEESTD.2013.6679210"/>
</reference> <seriesInfo name="IEEE Std" value="1901.2a"/>
</reference>
<reference anchor="ITU-T_G.9903" <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
target="https://www.itu.int/rec/T-REC-G.9903"> 415.xml"/>
<front> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3
<title> Narrowband orthogonal frequency division multiplexing 972.xml"/>
power line communication transceivers for
G3-PLC networks
</title>
<author>
<organization> International Telecommunication Union</organization>
</author>
<date month="August" year="2017"/> <reference anchor="EUI-64" target="https://standards.ieee.org/wp-content
</front> /uploads/import/documents/tutorials/eui.pdf">
<front>
<title> Guidelines for Use of Extended
Unique Idenfier (EUI), Organizationally Unique Identifier (OUI),
and Company ID (CID)
</title>
<author>
<organization>IEEE Standards Association</organization>
</author>
<date month="August" year="2017"/>
</front>
</reference>
<seriesInfo name="ITU-T" value="G.9903"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
</reference> 981.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4
963.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5
535.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7
217.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7
973.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
036.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
065.xml"/>
<?rfc include='reference.RFC.2119.xml'?> <!-- [I-D.ietf-roll-aodv-rpl] IESG state AD is watching. Changed to long
<?rfc include='reference.RFC.2464.xml'?> format because Anand's initials were incorrect in the output -->
<?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'?>
<reference anchor="IEEE_1901.1" <reference anchor="I-D.ietf-roll-aodv-rpl" target="https://datatracker.ietf.org/
target="https://ieeexplore.ieee.org/document/8360785"> doc/html/draft-ietf-roll-aodv-rpl-15">
<front> <front>
<title> Standard for Medium Frequency (less than 15 MHz) <title>Supporting Asymmetric Links in Low Power Networks: AODV-RPL</title>
Power Line Communications for Smart Grid Applications <author initials="C. E." surname="Perkins" fullname="Charles E. Perkins">
</title> <organization>Lupin Lodge</organization>
<author> </author>
<organization> IEEE-SA Standards Board </organization> <author initials="S.V.R." surname="Anand" fullname="S.V.R Anand">
</author> <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="Internet-Draft" value="draft-ietf-roll-aodv-rpl-15"/>
</reference>
<date month="May" year="2018"/> <!-- [I-D.ietf-6tisch-minimal-security] Published as RFC 9031 -->
</front>
<seriesInfo name="IEEE" value="1901.1"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
</reference> 031.xml"/>
</references>
<references title="Informative References"> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
<reference anchor="IEEE_1901.2a" 010.xml"/>
target="https://standards.ieee.org/findstds/standard/1901.2a-2015.html"> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7
<front> 925.xml"/>
<title> IEEE Standard for Low-Frequency (less than 500 kHz) <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5
Narrowband Power Line Communications for Smart Grid 191.xml"/>
Applications - Amendment 1
</title>
<author>
<organization>IEEE-SA Standards Board</organization>
</author>
<date month="September" year="2015"/> <!-- [I-D.ietf-6tisch-dtsecurity-zerotouch-join] IESG state Expired -->
</front>
<seriesInfo name="IEEE" value="1901.2a"/>
</reference>
<?rfc include='reference.RFC.8415.xml'?> <xi:include href="https://datatracker.ietf.org/doc/bibxml3/draft-ietf-6t
<?rfc include='reference.RFC.3972.xml'?> isch-dtsecurity-zerotouch-join.xml"/>
<reference anchor="EUI-64"
target="https://standards.ieee.org/content/dam/ieee-standards/standards/w
eb/documents/tutorials/eui.pdf">
<front>
<title> Guidelines for 64-bit Global Identifier (EUI-64) Registration
Authority
</title>
<author>
<organization>IEEE-SA Standards Board</organization>
</author>
<date month="March" year="1997"/>
</front>
<seriesInfo name="IEEE" value="EUI-64"/>
</reference>
<?rfc include='reference.RFC.8981.xml'?> <!-- [I-D.ietf-emu-eap-noob] Published as RFC 9140 -->
<?rfc include='reference.RFC.4963.xml'?>
<?rfc include='reference.RFC.5535.xml'?> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
<?rfc include='reference.RFC.7217.xml'?> 140.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'?>
<reference anchor="SCENA"
target="https://ieeexplore.ieee.org/document/7467440">
<front>
<title> State of the Art in Power Line Communications: From the Appli
cations to the Medium
</title>
<author fullname="Cristina Cano">
<organization>IEEE JOURNAL ON SELECTED AREAS IN COMMUNICATIONS</organ
ization>
</author>
<author fullname="Alberto Pittolo">
<organization>IEEE JOURNAL ON SELECTED AREAS IN COMMUNICATIONS</organ
ization>
</author>
<author fullname="David Malone">
<organization>IEEE JOURNAL ON SELECTED AREAS IN COMMUNICATIONS</organ
ization>
</author>
<author fullname="Lutz Lampe">
<organization>IEEE JOURNAL ON SELECTED AREAS IN COMMUNICATIONS</organ
ization>
</author>
<date month="July" year="2016"/>
</front>
</reference>
</references>
</back>
<reference anchor="SCENA" target="https://ieeexplore.ieee.org/document/7
467440">
<front>
<title> State of the Art in Power Line Communications: From the Appl
ications to the Medium
</title>
<author initials="C." surname="Cano" fullname="Cristina Cano">
<organization>IEEE JOURNAL ON SELECTED AREAS IN COMMUNICATIONS</or
ganization>
</author>
<author initials="A." surname="Pittolo" fullname="Alberto Pittolo">
<organization>IEEE JOURNAL ON SELECTED AREAS IN COMMUNICATIONS</or
ganization>
</author>
<author initials="D." surname="Malone" fullname="David Malone">
<organization>IEEE JOURNAL ON SELECTED AREAS IN COMMUNICATIONS</or
ganization>
</author>
<author initials="L." surname="Lampe" fullname="Lutz Lampe">
<organization>IEEE JOURNAL ON SELECTED AREAS IN COMMUNICATIONS</or
ganization>
</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> </rfc>
 End of changes. 103 change blocks. 
992 lines changed or deleted 1101 lines changed or added

This html diff was produced by rfcdiff 1.48.