[要約] RFC 9354は、電力線通信（PLC）ネットワーク上でIPv6パケットを転送する方法を記述しており、主な目的は、電力線を利用した通信を拡張し、将来のアプリケーションに対応するためのIPv6の需要を満たすことです。
Internet Engineering Task Force (IETF) J. Hou
Request for Comments: 9354 B. Liu
Category: Standards Track Huawei Technologies
ISSN: 2070-1721 Y-G. Hong
Daejeon University
X. Tang
SGEPRI
C. Perkins
Lupin Lodge
January 2023
Power Line Communication (PLC), namely using electric power lines for indoor and outdoor communications, has been widely applied to support Advanced Metering Infrastructure (AMI), especially smart meters for electricity. The existing electricity infrastructure facilitates the expansion of PLC deployments due to its potential advantages in terms of cost and convenience. Moreover, a wide variety of accessible devices raises the potential demand of IPv6 for future applications. This document describes how IPv6 packets are transported over constrained PLC networks, such as those described in ITU-T G.9903, IEEE 1901.1, and IEEE 1901.2.
電力線通信（PLC）、すなわち屋内および屋外通信に電力線を使用して、高度な計量インフラストラクチャ（AMI）、特に電気のスマートメーターをサポートするために広く適用されています。既存の電力インフラストラクチャは、コストと利便性の面での潜在的な利点により、PLC展開の拡大を促進します。さらに、さまざまなアクセス可能なデバイスが、将来のアプリケーションに対するIPv6の潜在的な需要を高めます。このドキュメントでは、ITU-T G.9903、IEEE 1901.1、およびIEEE 1901.2に記載されているような、制約付きPLCネットワーク上でIPv6パケットがどのように輸送されるかについて説明します。
This is an Internet Standards Track document.
これは、インターネット標準トラックドキュメントです。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841.
このドキュメントは、インターネットエンジニアリングタスクフォース（IETF）の製品です。IETFコミュニティのコンセンサスを表しています。公開レビューを受けており、インターネットエンジニアリングステアリンググループ（IESG）からの出版が承認されています。インターネット標準の詳細については、RFC 7841のセクション2で入手できます。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc9354.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、https：//www.rfc-editor.org/info/rfc9354で取得できます。
Copyright (c) 2023 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（c）2023 IETF Trustおよび文書著者として特定された人。無断転載を禁じます。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.
このドキュメントは、BCP 78およびIETFドキュメント（https://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション4.Eで説明されており、改訂されたBSDライセンスで説明されている保証なしで提供されるように、改訂されたBSDライセンステキストを含める必要があります。
1. Introduction
2. Requirements Notation and Terminology
3. Overview of PLC
3.1. Protocol Stack
3.2. Addressing Modes
3.3. Maximum Transmission Unit
3.4. Routing Protocol
4. IPv6 over PLC
4.1. Stateless Address Autoconfiguration
4.2. IPv6 Link-Local Address
4.3. Unicast Address Mapping
4.3.1. Unicast Address Mapping for IEEE 1901.1
4.3.2. Unicast Address Mapping for IEEE 1901.2 and ITU-T
G.9903
4.4. Neighbor Discovery
4.5. Header Compression
4.6. Fragmentation and Reassembly
5. Internet Connectivity Scenarios and Topologies
6. Operations and Manageability Considerations
7. IANA Considerations
8. Security Considerations
9. References
9.1. Normative References
9.2. Informative References
Acknowledgements
Authors' Addresses
The idea of using power lines for both electricity supply and communication can be traced back to the beginning of the last century. Using the existing power grid to transmit messages, Power Line Communication (PLC) is a good candidate for supporting various service scenarios such as in houses and offices, in trains and vehicles, in smart grids, and in Advanced Metering Infrastructure (AMI) [SCENA]. The data-acquisition devices in these scenarios share common features such as fixed position, large quantity of nodes, low data rate, and low power consumption.
電力供給と通信の両方に送電線を使用するというアイデアは、前世紀の初めにまでさかのぼることができます。既存の電源グリッドを使用してメッセージを送信すると、電力線通信（PLC）は、家やオフィス、電車や車両、スマートグリッド、高度な計量インフラストラクチャ（AMI）などのさまざまなサービスシナリオをサポートするための優れた候補です[シナミ]。これらのシナリオのデータ取得デバイスは、固定位置、大量のノード、低データレート、低消費電力などの共通の機能を共有しています。
Although PLC technology has evolved over several decades, it has not been fully adapted for IPv6-based constrained networks. The resource-constrained scenarios related to the Internet of Things (IoT) lie in the low voltage PLC networks with most applications in the area of AMI, vehicle-to-grid communications, in-home energy management, and smart street lighting. IPv6 is important for PLC networks, due to its large address space and efficient address autoconfiguration.
PLCテクノロジーは数十年にわたって進化してきましたが、IPv6ベースの制約ネットワークには完全に適合していません。モノのインターネット（IoT）に関連するリソース制約のシナリオは、AMI、車両間通信、在宅エネルギー管理、スマートストリート照明のエリアにほとんどのアプリケーションを備えた低電圧PLCネットワークにあります。IPv6は、アドレススペースが大きくなり、アドレスの自動構成が効率的であるため、PLCネットワークにとって重要です。
This document provides a brief overview of PLC technologies. Some of them have LLN (Low-Power and Lossy Network) characteristics, i.e., limited power consumption, memory, and processing resources. This document specifies the transmission of IPv6 packets over those constrained PLC networks. The general approach is to adapt elements of the 6LoWPAN (IPv6 over Low-Power Wireless Personal Area Network) and 6lo (IPv6 over Networks of Resource-constrained Nodes) specifications, such as those described in [RFC4944], [RFC6282], [RFC6775], and [RFC8505], to constrained PLC networks.
このドキュメントは、PLCテクノロジーの簡単な概要を提供します。それらのいくつかは、LLN（低電力および損失のあるネットワーク）の特性、つまり限られた消費、メモリ、および処理リソースを持っています。このドキュメントは、制約されたPLCネットワークにおけるIPv6パケットの送信を指定します。一般的なアプローチは、[RFC4944]、[RFC6282]、[RFC67755に記載されているような、6lowpan（低電力ワイヤレスパーソナルエリアネットワーク上のIPv6）および6lo（リソース制約ノードのネットワーク上のIPv6）仕様を適応させることです。]、[RFC8505]、制約されたPLCネットワーク。
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 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
この文書のキーワード "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", および "OPTIONAL" はBCP 14 [RFC2119] [RFC8174]で説明されているように、すべて大文字の場合にのみ解釈されます。
This document uses the following acronyms and terminologies:
このドキュメントでは、次の頭字語と用語を使用します。
6BBR:
6bbr：
6LoWPAN Backbone Router
6lowpanバックボーンルーター
6LBR:
6LBR：
6LoWPAN Border Router
6Lowpan Border Router
6lo:
6lo：
IPv6 over Networks of Resource-constrained Nodes
リソースに制約のあるノードのネットワーク上のIPv6
6LoWPAN:
6lowpan：
IPv6 over Low-Power Wireless Personal Area Network
低電力ワイヤレスパーソナルエリアネットワークを超えるIPv6
6LR:
6lr：
6LoWPAN Router
6lowpanルーター
AMI:
アミ：
Advanced Metering Infrastructure
高度な計量インフラストラクチャ
BBPLC:
BBPLC：
Broadband Power Line Communication
ブロードバンド電力線通信
Coordinator:
コーディネーター：
A device capable of relaying messages
メッセージを中継できるデバイス
DAD:
お父さん：
Duplicate Address Detection
複製アドレス検出
EUI:
EUI：
Extended Unique Identifier
拡張された一意の識別子
IID:
IID：
Interface Identifier
インターフェイス識別子
LLN:
LLN：
Low-Power and Lossy Network
低電力と損失のあるネットワーク
MTU:
MTU：
Maximum Transmission Unit
最大送信ユニット
NBPLC:
NBPLC：
Narrowband Power Line Communication
狭帯域電力線通信
PAN:
パン：
Personal Area Network
パーソナルエリアネットワーク
PANC:
パンク：
PAN Coordinator, a coordinator that also acts as the primary controller of a PAN
パンコーディネーター、パンの主要なコントローラーとしても機能するコーディネーター
PLC:
PLC：
Power Line Communication
電力線通信
PLC device:
PLCデバイス：
An entity that follows the PLC standards and implements the protocol stack described in this document
PLC標準に従い、このドキュメントに記載されているプロトコルスタックを実装するエンティティ
RA:
RA：
Router Advertisement
ルーター広告
RPL:
RPL：
Routing Protocol for Low-Power and Lossy Networks
低電力および損失ネットワーク用のルーティングプロトコル
Below is a mapping table of the terminology between [IEEE_1901.2], [IEEE_1901.1], [ITU-T_G.9903], and this document.
以下は、[IEEE_1901.2]、[IEEE_1901.1]、[ITU-T_G.9903]、およびこの文書の間の用語のマッピングテーブルです。
+=================+=============+===============+===============+
| IEEE 1901.2 | IEEE 1901.1 | ITU-T G.9903 | This document |
+=================+=============+===============+===============+
| PAN Coordinator | Central | PAN | PAN |
| | Coordinator | Coordinator | Coordinator |
+-----------------+-------------+---------------+---------------+
| Coordinator | Proxy | Full-Function | Coordinator |
| | Coordinator | Device | |
+-----------------+-------------+---------------+---------------+
| Device | Station | PAN Device | PLC Device |
+-----------------+-------------+---------------+---------------+
Table 1: Terminology Mapping between PLC Standards
表1：PLC標準間の用語マッピング
PLC technology enables convenient two-way communications for home users and utility companies to monitor and control electrically connected devices such as electricity meters and street lights. PLC can also be used in smart home scenarios, such as the control of indoor lights and switches. Due to the large range of communication frequencies, PLC is generally classified into two categories: Narrowband PLC (NBPLC) for automation of sensors (which have a low frequency band and low power cost) and Broadband PLC (BBPLC) for home and industry networking applications.
PLCテクノロジーにより、ホームユーザーやユーティリティ会社向けの便利な双方向通信が、電力メーターや街路灯などの電気的に接続されたデバイスを監視および制御できるようにします。PLCは、屋内ライトやスイッチの制御など、スマートホームシナリオでも使用できます。通信周波数の範囲が多いため、PLCは一般に2つのカテゴリに分類されます：センサーの自動化（低周波バンドと低電力コストを持つ）およびホームおよび業界のネットワーキングアプリケーション用のブロードバンドPLC（BBPLC）の自動化。
Various standards have been addressed on the Media Access Control (MAC) and Physical (PHY) layers. For example, standards for BBPLC (1.8-250 MHz) include IEEE 1901 and ITU-T G.hn, and standards for NBPLC (3-500 kHz) include ITU-T G.9902 (G.hnem), ITU-T G.9903 (G3-PLC) [ITU-T_G.9903], ITU-T G.9904 (PRIME), IEEE 1901.2 (a combination of G3-PLC and PRIME PLC) [IEEE_1901.2], and IEEE 1901.2a (an amendment to IEEE 1901.2) [IEEE_1901.2a].
メディアアクセス制御（MAC）および物理（PHY）層でさまざまな標準が対処されています。たとえば、BBPLCの標準（1.8-250 MHz）にはIEEE 1901およびITU-T G.HN、およびNBPLCの標準（3-500 kHz）が含まれます。.9903（G3-PLC）[ITU-T_G.9903]、ITU-T G.9904（PRIME）、IEEE 1901.2（G3-PLCとPRIME PLCの組み合わせ）[IEEE_1901.2]、およびIEEE 1901.2A（IEEE 1901.2の修正）[IEEE_1901.2a]。
IEEE 1901.1 [IEEE_1901.1], 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 the needs for bandwidth versus communication range and is thus a promising option for 6lo applications.
IEEE 1901.1 [IEEE_1901.1]は、12 MHz未満の中周波数帯域を対象としたPLC標準であり、Smart Grid Powerline Communication Working Group（SGPLC WG）のIEEE標準によって公開されました。IEEE 1901.1は、帯域幅と通信範囲のニーズのバランスをとるため、6LOアプリケーションの有望なオプションです。
This specification is focused on IEEE 1901.1, IEEE 1901.2, and ITU-T G.9903.
この仕様は、IEEE 1901.1、IEEE 1901.2、およびITU-T G.9903に焦点を当てています。
The protocol stack for IPv6 over PLC is illustrated in Figure 1. The PLC MAC and PLC PHY layers correspond to the layers described in IEEE 1901.1, IEEE 1901.2, or ITU-T G.9903. The 6lo adaptation layer for PLC is illustrated in Section 4. For multihop tree and mesh topologies, a routing protocol is likely to be necessary. The routes can be built in mesh-under mode at Layer 2 or in route-over mode at Layer 3, as explained in Sections 3.4 and 4.4.
PLCを介したIPv6のプロトコルスタックを図1に示します。PLCMACおよびPLC PHY層は、IEEE 1901.1、IEEE 1901.2、またはITU-T G.9903に記載されているレイヤーに対応しています。PLCの6LO適応層は、セクション4に示されています。マルチホップツリーとメッシュトポロジの場合、ルーティングプロトコルが必要になる可能性があります。セクション3.4および4.4で説明されているように、ルートはレイヤー2のメッシュアンダーモードまたはレイヤー3のルートオーバーモードで構築できます。
+----------------------------------------+
| Application Layer |
+----------------------------------------+
| Transport Layer |
+----------------------------------------+
| |
| IPv6 Layer |
| |
+----------------------------------------+
| Adaptation Layer for IPv6 over PLC |
+----------------------------------------+
| PLC MAC Layer |
+----------------------------------------+
| PLC PHY Layer |
+----------------------------------------+
Figure 1: PLC Protocol Stack
図1：PLCプロトコルスタック
Each PLC device has a globally unique long address of 48 bits [IEEE_1901.1] or 64 bits [IEEE_1901.2] [ITU-T_G.9903] and a short address of 12 bits [IEEE_1901.1] or 16 bits [IEEE_1901.2] [ITU-T_G.9903]. The long address is set by the manufacturer according to the IEEE EUI-48 MAC address or the IEEE EUI-64 address. Each PLC device joins the network by using the long address and communicates with other devices by using the short address after joining the network. Short addresses can be assigned during the onboarding process, by the PANC or the JRC (join registrar/ coordinator) in CoJP (Constrained Join Protocol) [RFC9031].
各PLCデバイスには、48ビット[IEEE_1901.1]または64ビット[IEEE_1901.2] [ITU-T_G.9903]のグローバルな一意の長いアドレスと、12ビット[IEEE_1901.1]または16ビット[IEEE_1901の短いアドレスがあります。2] [ITU-T_G.9903]。長い住所は、IEEE EUI-48 MACアドレスまたはIEEE EUI-64アドレスに従って製造業者によって設定されます。各PLCデバイスは、長いアドレスを使用してネットワークに結合し、ネットワークに参加した後に短いアドレスを使用して他のデバイスと通信します。オンボーディングプロセス中に、PANCまたはJRC（Registrar/ Coordinatorに参加）でCOJP（制約付きJoin Protocol）[RFC9031]によって、短いアドレスを割り当てることができます。
The Maximum Transmission Unit (MTU) of the MAC layer determines whether fragmentation and reassembly are needed at the adaptation layer of IPv6 over PLC. IPv6 requires an MTU of 1280 octets or greater; thus, for a MAC layer with an MTU lower than this limit, fragmentation and reassembly at the adaptation layer are required.
MAC層の最大透過ユニット（MTU）は、PLCを介したIPv6の適応層で断片化と再組み立てが必要かどうかを決定します。IPv6には、1280オクテット以上のMTUが必要です。したがって、この制限よりも低いMTUのMACレイヤーの場合、適応層での断片化と再組み立てが必要です。
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 value of 1280 bytes was updated in 2015 [IEEE_1901.2a]). Though these two technologies can support IPv6 originally without fragmentation and reassembly, it is possible to configure a smaller MTU in a high-noise communication environment. Thus, the 6lo functions, including header compression, fragmentation, and reassembly, are still applicable and useful.
IEEE 1901.1 Macは、最大2031オクテットまでの上層層パケットをサポートしています。IEEE 1901.2 Macレイヤーは1576オクテットのMTUをサポートしています（2015年に1280バイトの元の値が更新されました[IEEE_1901.2A]）。これらの2つのテクノロジーは、元々は断片化や再組み立てなしでIPv6をサポートできますが、高ノイズ通信環境でより小さなMTUを構成することができます。したがって、ヘッダー圧縮、断片化、再組み立てなどの6LO関数は、まだ適用可能で有用です。
The MTU for ITU-T G.9903 is 400 octets, which is insufficient for supporting IPv6's MTU. For this reason, fragmentation and reassembly are required for G.9903-based networks to carry IPv6.
ITU-T G.9903のMTUは400オクテットで、IPv6のMTUをサポートするには不十分です。このため、G.9903ベースのネットワークにはIPv6を運ぶためには、断片化と再組み立てが必要です。
Routing protocols suitable for use in PLC networks include:
PLCネットワークでの使用に適したルーティングプロトコルは次のとおりです。
* RPL (Routing Protocol for Low-Power and Lossy Networks) [RFC6550] is a Layer 3 routing protocol. AODV-RPL [AODV-RPL] updates RPL to include reactive, point-to-point, and asymmetric routing. IEEE 1901.2 specifies Information Elements (IEs) with MAC layer metrics, which can be provided to a Layer 3 routing protocol for parent selection.
* RPL（低電力および損失ネットワーク用のルーティングプロトコル）[RFC6550]は、レイヤー3ルーティングプロトコルです。AODV-RPL [AODV-RPL]は、RPLを更新して、反応性、ポイントツーポイント、および非対称ルーティングを含めます。IEEE 1901.2は、MACレイヤーメトリックを使用して情報要素（IE）を指定します。これは、親選択のためにレイヤー3ルーティングプロトコルに提供できます。
* IEEE 1901.1 supports the mesh-under routing scheme. Each PLC node maintains a routing table, in which each route entry comprises the short addresses of the destination and the related next hop. The route entries are built during the network establishment via a pair of association request/confirmation messages. The route entries can be changed via a pair of proxy change request/ confirmation messages. These association and proxy change messages must be approved by the central coordinator (PANC in this document).
* IEEE 1901.1は、メッシュアンダールーティングスキームをサポートしています。各PLCノードには、各ルートエントリが宛先の短いアドレスと関連する次のホップを含むルーティングテーブルを維持します。ルートエントリは、ネットワークの確立中に、一対の協会リクエスト/確認メッセージを介して構築されます。ルートエントリは、プロキシ変更リクエスト/確認メッセージのペアを介して変更できます。これらの協会とプロキシの変更メッセージは、中央コーディネーターによって承認されなければなりません（このドキュメントのPANC）。
* LOADng (Lightweight On-demand Ad hoc Distance vector routing protocol, Next Generation) is a reactive protocol operating at Layer 2 or Layer 3. Currently, LOADng is supported in ITU-T G.9903 [ITU-T_G.9903], and the IEEE 1901.2 standard refers to ITU-T G.9903 for LOAD-based networks.
* loadng（軽量オンデマンドアドホック距離ベクトルルーティングプロトコル、次世代）は、レイヤー2またはレイヤー3で動作するリアクティブプロトコルです。現在、LoadNGはITU-T G.9903 [ITU-T_G.9903]、およびIEEE 1901.2標準は、負荷ベースのネットワークのITU-T G.9903を指します。
A PLC node distinguishes between an IPv6 PDU and a non-IPv6 PDU based on the equivalent of an Ethertype in a Layer 2 PLC PDU. [RFC7973] defines an Ethertype of "A0ED" for LoWPAN encapsulation, and this information can be carried in the IE field in the MAC header of [IEEE_1901.2] or [ITU-T_G.9903]. And regarding [IEEE_1901.1], the IP packet type has been defined with the corresponding MAC Service Data Unit (MSDU) type value 49. And the 4-bit Internet Protocol version number in the IP header helps to distinguish between an IPv4 PDU and an IPv6 PDU.
PLCノードは、レイヤー2 PLC PDUのEtherTypeに相当するIPv6 PDUと非IPV6 PDUを区別します。[RFC7973]は、ローパンのカプセル化の「A0ed」の倫理を定義し、この情報は[IEEE_1901.2]または[ITU-T_G.9903]のMACヘッダーのIEフィールドで伝えることができます。[IEEE_1901.1]に関して、IPパケットタイプは、対応するMACサービスデータユニット（MSDU）タイプ値49で定義されています。また、IPヘッダーの4ビットインターネットプロトコルバージョン番号は、IPv4 PDUとIPv4 PDUを区別するのに役立ちます。IPv6 PDU。
6LoWPAN and 6lo standards, as described in [RFC4944], [RFC6282], [RFC6775], and [RFC8505], provide useful functionality, including link-local IPv6 addresses, stateless address autoconfiguration, neighbor discovery, header compression, fragmentation, and reassembly. However, due to the different characteristics of the PLC media, the 6LoWPAN adaptation layer, as it is, cannot perfectly fulfill the requirements of PLC environments. These considerations suggest the need for a dedicated adaptation layer for PLC, which is detailed in the following subsections.
[RFC4944]、[RFC6282]、[RFC6775]、および[RFC8505]で説明されているように、6Lowpanおよび6lo標準は、Link-Local IPv6アドレス、ステートレスアドレスの自動化、近隣発見、ヘッダーの圧縮、断片化、および断片化を含む有用な機能を提供します。。ただし、PLCメディアの特性が異なるため、6lowpan適応層は、PLC環境の要件を完全に満たすことはできません。これらの考慮事項は、PLCの専用適応層の必要性を示唆しています。これは、以下のサブセクションで詳述されています。
To obtain an IPv6 Interface Identifier (IID), a PLC device performs stateless address autoconfiguration [RFC4944]. The autoconfiguration can be based on either a long or short link-layer address.
IPv6インターフェイス識別子（IID）を取得するために、PLCデバイスはStateless Address Autoconfiguration [RFC4944]を実行します。自動構成は、長いまたは短いリンク層アドレスのいずれかに基づいています。
The IID can be based on the device's 48-bit MAC address or its EUI-64 identifier [EUI-64]. A 48-bit MAC address MUST first be extended to a 64-bit IID by inserting 0xFFFE at the fourth and fifth octets as specified in [RFC2464]. The IPv6 IID is derived from the 64-bit IID by inverting the U/L (Universal/Local) bit [RFC4291].
IIDは、デバイスの48ビットMACアドレスまたはそのEUI-64識別子[EUI-64]に基づくことができます。[RFC2464]で指定されているように、48ビットのMACアドレスを最初に64ビットIIDに拡張する必要があります。IPv6 IIDは、U/L（ユニバーサル/ローカル）ビット[RFC4291]を反転させることにより、64ビットIIDから派生しています。
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 follows:
IEEE 1901.2およびITU-T G.9903の場合、48ビットの「Pseudo-Address」は、16ビットPAN ID、16ゼロビット、16ビットの短いアドレスによって形成されます。
16_bit_PAN:0000:16_bit_short_address
16_bit_pan：0000：16_bit_short_address
Then, the 64-bit IID MUST be derived by inserting the 16-bit 0xFFFE into as follows:
次に、64ビットIIDは、16ビット0xfffeを次のように挿入して導出する必要があります。
16_bit_PAN:00FF:FE00:16_bit_short_address
16_bit_pan：00ff：fe00：16_bit_short_address
For the 12-bit short addresses used by IEEE 1901.1, the 48-bit pseudo-address is formed by a 24-bit NID (Network Identifier, YYYYYY), 12 zero bits, and a 12-bit TEI (Terminal Equipment Identifier, XXX) as follows:
IEEE 1901.1が使用する12ビットの短いアドレスの場合、48ビットの擬似アドレスは、24ビットNID（ネットワーク識別子、yyyyyy）、12ゼロビット、および12ビットTEI（ターミナル機器識別子、xxx）によって形成されます。） 次のように：
YYYY:YY00:0XXX
yyyy：yy00：0xxx
The 64-bit IID MUST be derived by inserting the 16-bit 0xFFFE into this 48-bit pseudo-address as follows:
64ビットIIDは、次のように、この48ビットの擬似アドレスに16ビット0xfffeを挿入することによって導出する必要があります。
YYYY:YYFF:FE00:0XXX
yyyy：yyff：fe00：0xxx
As investigated in [RFC7136], aside from the method discussed in [RFC4291], other IID-generation methods defined by the IETF do not imply any additional semantics for the Universal/Local (U/L) bit (bit 6) and the Individual/Group bit (bit 7). Therefore, these two bits are not reliable indicators. Thus, when using an IID derived by a short address, the operators of the PLC network can choose whether or not to comply with the original meaning of these two bits. If they choose to comply with the original meaning, these two bits MUST both be set to zero, since the IID derived from the short address is not global. In order to avoid any ambiguity in the derived IID, these two bits MUST NOT be a valid part of the PAN ID (for IEEE 1901.2 and ITU-T G.9903) or NID (for IEEE 1901.1). For example, the PAN ID or NID must always be chosen so that the two bits are zeros or the high six bits in PAN ID or NID are left shifted by two bits. If they choose not to comply with the original meaning, the operator must be aware that these two bits are not reliable indicators, and the IID cannot be transformed back into a short link-layer address via a reverse operation of the mechanism presented above. However, the short address can still be obtained via the Unicast Address Mapping mechanism described in Section 4.3.
[RFC7136]で調査されたように、[RFC4291]で説明されている方法は別として、IETFによって定義される他のIID世代の方法は、ユニバーサル/ローカル（U/L）ビット（ビット6）および個々のセマンティクスを意味しません。/グループビット（ビット7）。したがって、これらの2つのビットは信頼できる指標ではありません。したがって、短いアドレスによって導出されたIIDを使用する場合、PLCネットワークの演算子は、これら2つのビットの元の意味に準拠するかどうかを選択できます。彼らが元の意味に準拠することを選択した場合、短いアドレスから派生したIIDはグローバルではないため、これらの2つのビットは両方ともゼロに設定する必要があります。導出されたIIDのあいまいさを回避するために、これらの2つのビットは、PAN ID（IEEE 1901.2およびITU-T G.9903）またはNID（IEEE 1901.1の場合）の有効な部分であってはなりません。たとえば、2つのビットがゼロまたはパンIDまたはNIDの6ビットの高さになるように、パンIDまたはNIDを常に選択する必要があります。元の意味に準拠しないことを選択した場合、オペレーターは、これらの2つのビットが信頼できる指標ではないことを認識する必要があり、IIDは上記のメカニズムの逆動作を介して短いリンク層アドレスに戻すことはできません。ただし、セクション4.3で説明したユニキャストアドレスマッピングメカニズムを介して、短いアドレスは引き続き取得できます。
For privacy reasons, the IID derived from the MAC address (with padding and bit clamping) SHOULD only be used for link-local address configuration. A PLC host SHOULD use the IID derived from the short link-layer address to configure IPv6 addresses used for communication with the public network; otherwise, the host's MAC address is exposed. As per [RFC8065], when short addresses are used on PLC links, a shared secret key or version number from the Authoritative Border Router Option [RFC6775] can be used to improve the entropy of the hash input. Thus, the generated IID can be spread out to the full range of the IID address space while stateless address compression is still allowed. By default, the hash algorithm SHOULD be SHA256, using the version number, the PAN ID or NID, and the short address as the input arguments, and the 256-bit hash output is truncated into the IID by taking the high 64 bits.
プライバシー上の理由から、MACアドレス（パディングとビットクランプ付き）から派生したIIDは、Link-Localアドレス構成にのみ使用する必要があります。PLCホストは、短いリンク層アドレスから派生したIIDを使用して、パブリックネットワークとの通信に使用されるIPv6アドレスを構成する必要があります。それ以外の場合、ホストのMACアドレスが公開されます。[RFC8065]に従って、PLCリンクで短いアドレスを使用する場合、HASH入力のエントロピーを改善するために、権威ある境界ルーターオプション[RFC6775]の共有シークレットキーまたはバージョン番号を使用できます。したがって、生成されたIIDは、IIDアドレス空間の全範囲に広げることができますが、ステートレスアドレスの圧縮はまだ許可されています。デフォルトでは、ハッシュアルゴリズムは、バージョン番号、PAN IDまたはNID、および短いアドレスを入力引数として使用してSHA256である必要があります。
The IPv6 link-local address [RFC4291] for a PLC interface is formed by appending the IID, as defined above, to the prefix FE80::/64 (see Figure 2).
PLCインターフェイスのIPv6 Link-Localアドレス[RFC4291]は、上記のようにIIDをプレフィックスFE80 ::/64に追加することにより形成されます（図2を参照）。
10 bits 54 bits 64 bits
+----------+-----------------------+----------------------------+
|1111111010| (zeros) | Interface Identifier |
+----------+-----------------------+----------------------------+
Figure 2: IPv6 Link-Local Address for a PLC Interface
図2：PLCインターフェイスのIPv6リンクローカルアドレス
The address-resolution procedure for mapping IPv6 unicast addresses into PLC link-layer addresses follows the general description in Section 7.2 of [RFC4861]. [RFC6775] 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. [RFC8505] further improves the registration procedure by enabling multiple LLNs to form an IPv6 subnet and by inserting a link-local address registration to better serve proxy registration of new devices.
IPv6ユニキャストアドレスをPLCリンク層アドレスにマッピングするアドレス解像度手順は、[RFC4861]のセクション7.2の一般的な説明に続きます。[RFC6775]マルチキャストNSの使用を排除することにより、この手順を改善します（近隣の勧誘）。解像度は、ルーターでのアドレス登録中に作成されたNCES（隣接キャッシュエントリ）によって実現されます。[RFC8505]は、複数のLLNがIPv6サブネットを形成できるようにし、リンクローカルアドレス登録を挿入して新しいデバイスのプロキシ登録をより適切に対応できるようにすることにより、登録手順をさらに改善します。
The Source Link-Layer Address and Target Link-Layer Address options for IEEE_1901.1 used in the NS and Neighbor Advertisement (NA) have the following form.
NSおよびNeighbor Advertisement（NA）で使用されるIEEE_1901.1のソースリンクレイヤーアドレスとターゲットリンクレイヤーアドレスオプションには、次の形式があります。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length=1 | NID :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
:NID (continued)| Padding (all zeros) | TEI |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: Unicast Address Mapping for IEEE 1901.1
図3：IEEE 1901.1のユニキャストアドレスマッピング
Option fields:
オプションフィールド：
Type:
タイプ：
1 for Source Link-Layer Address and 2 for Target Link-Layer Address.
ソースリンク層アドレスの場合は1、ターゲットリンク層アドレスの場合は2。
Length:
長さ：
The length of this option (including Type and Length fields) in units of 8 octets. The value of this field is 1 for the 12-bit IEEE 1901.1 PLC short addresses.
8オクテットのユニットのこのオプションの長さ（タイプフィールドと長さフィールドを含む）。このフィールドの値は、12ビットIEEE 1901.1 PLCショートアドレスの場合は1です。
NID:
NID：
24-bit Network Identifier
24ビットネットワーク識別子
Padding:
パディング：
12 zero bits
12ゼロビット
TEI:
Tei：
12-bit Terminal Equipment Identifier
12ビット端子機器識別子
The Source Link-Layer Address and Target Link-Layer Address options for IEEE_1901.2 and ITU-T G.9903 used in the NS and NA have the following form.
IEEE_1901.2およびNSおよびNAで使用されるIEEE_1901.2およびITU-T G.9903のソースリンクレイヤーアドレスとターゲットリンクレイヤーアドレスオプションには、次の形式があります。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length=1 | PAN ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Padding (all zeros) | Short Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: Unicast Address Mapping for IEEE 1901.2
図4：IEEE 1901.2のユニキャストアドレスマッピング
Option fields:
オプションフィールド：
Type:
タイプ：
1 for Source Link-Layer Address and 2 for Target Link-Layer Address.
ソースリンク層アドレスの場合は1、ターゲットリンク層アドレスの場合は2。
Length:
長さ：
The length of this option (including Type and Length fields) in units of 8 octets. The value of this field is 1 for the 16-bit IEEE 1901.2 PLC short addresses.
8オクテットのユニットのこのオプションの長さ（タイプフィールドと長さフィールドを含む）。このフィールドの値は、16ビットIEEE 1901.2 PLCショートアドレスの場合は1です。
PAN ID:
パンID：
16-bit PAN IDentifier
16ビットパン識別子
Padding:
パディング：
16 zero bits
16ゼロビット
Short Address:
短い住所：
16-bit short address
16ビットの短いアドレス
Neighbor discovery procedures for 6LoWPAN networks are described in [RFC6775] and [RFC8505]. These optimizations support the registration of sleeping hosts. Although PLC devices are electrically powered, sleeping mode SHOULD still be used for power saving.
6lowpanネットワークの近隣発見手順は、[RFC6775]および[RFC8505]で説明されています。これらの最適化は、睡眠ホストの登録をサポートしています。PLCデバイスは電動式であるが、スリーピングモードは電力節約に使用する必要があります。
For IPv6 prefix dissemination, Router Solicitations (RSs) and Router Advertisements (RAs) MAY be used as per [RFC6775]. If the PLC network uses route-over mode, the IPv6 prefix MAY be disseminated by the Layer 3 routing protocol, such as RPL, which may include the prefix in the DIO (DODAG Information Object) message. As per [RFC9010], it is possible to have PLC devices configured as RPL-unaware leaves, which do not participate in RPL at all, along with RPL-aware PLC devices. In this case, the prefix dissemination SHOULD use the RS/RA messages.
IPv6プレフィックスの普及の場合、[RFC6775]に従って、ルーターの勧誘（RSS）およびルーター広告（RAS）を使用できます。PLCネットワークがルートオーバーモードを使用している場合、IPv6プレフィックスは、RPLなどのレイヤー3ルーティングプロトコルによって普及する場合があります。これには、DIO（DODAG情報オブジェクト）メッセージにプレフィックスが含まれる場合があります。[RFC9010]によると、RPL-Aware PLCデバイスとともに、RPLに参加しないRPL-Unawareの葉としてPLCデバイスを構成することができます。この場合、プレフィックスの普及はRS/RAメッセージを使用する必要があります。
For dissemination of context information, RAs MUST be used as per [RFC6775]. The 6LoWPAN context option (6CO) MUST be included in the RA to disseminate the Context IDs used for prefix and/or address compression.
コンテキスト情報の普及のために、[RFC6775]に従ってRASを使用する必要があります。6lowpanコンテキストオプション（6CO）をRAに含めて、プレフィックスおよび/またはアドレス指定に使用されるコンテキストIDを広める必要があります。
For address registration in route-over mode, a PLC device MUST register its addresses by sending a unicast link-local NS to the 6LR. If the registered address is link local, the 6LR SHOULD NOT further register it to the registrar (6LBR or 6BBR). Otherwise, the address MUST be registered via an ARO (Address Registration Option) or EARO (Extended Address Registration Option) included in the DAR (Duplicate Address Request) [RFC6775] or EDAR (Extended Duplicate Address Request) [RFC8505] messages. For PLC devices compliant with [RFC8505], the 'R' flag in the EARO MUST be set when sending NSs in order to extract the status information in the replied NAs from the 6LR. If DHCPv6 is used to assign addresses or the IPv6 address is derived from the unique long or short link-layer address, Duplicate Address Detection (DAD) SHOULD NOT be utilized. Otherwise, DAD MUST be performed at the 6LBR (as per [RFC6775]) or proxied by the routing registrar (as per [RFC8505]). The registration status is fed back via the DAC (Duplicate Address Confirmation) or EDAC (Extended Duplicate Address Confirmation) message from the 6LBR and the NA from the 6LR. Section 6 of [RFC8505] shows how devices that only behave as specified in [RFC6775] can work with devices that have been updated per [RFC8505].
ルートオーバーモードでのアドレス登録の場合、PLCデバイスは、ユニキャストリンクローカルNSを6LRに送信してアドレスを登録する必要があります。登録されたアドレスがLink Localの場合、6LRはそれをさらにレジストラ（6LBRまたは6BBR）に登録しないでください。それ以外の場合、アドレスは、ARO（アドレス登録オプション）またはDAR（Duplicateアドレスリクエスト）[RFC6775]またはEDAR（拡張重複したアドレスリクエスト）[RFC8505]メッセージに含まれるEARO（拡張アドレス登録オプション）を介して登録する必要があります。[RFC8505]に準拠したPLCデバイスの場合、6LRから応答したNASのステータス情報を抽出するために、NSSを送信するときにEAROの「R」フラグを設定する必要があります。DHCPV6がアドレスを割り当てるために使用されるか、IPv6アドレスが一意の長いリンク層アドレスまたは短いリンク層アドレスから派生している場合、複製アドレス検出（DAD）を利用しないでください。それ以外の場合、お父さんは6LBR（[RFC6775]に従って）で実行されるか、ルーティングレジストラ（[RFC8505]に従って）で誘惑する必要があります。登録ステータスは、6LBRからのDAC（複製アドレス確認）またはEDAC（拡張された複製アドレス確認）メッセージを介して供給されます。[RFC8505]のセクション6は、[RFC6775]で指定されているように振る舞うデバイス[RFC8505]ごとに更新されたデバイスでどのように動作するかを示しています。
For address registration in mesh-under mode, since all the PLC devices are link-local neighbors to the 6LBR, DAR/DAC or EDAR/EDAC messages are not required. A PLC device MUST register its addresses by sending a unicast NS message with an ARO or EARO. The registration status is fed back via the NA message from the 6LBR.
メッシュアンダーモードでのアドレス登録の場合、すべてのPLCデバイスは6LBRへのリンク局所ネイバーであるため、DAR/DACまたはEDAR/EDACメッセージは必要ありません。PLCデバイスは、AROまたはEAROでユニキャストNSメッセージを送信してアドレスを登録する必要があります。登録ステータスは、6LBRからのNAメッセージを介して供給されます。
IPv6 header compression in PLC is based on [RFC6282] (which updates [RFC4944]). [RFC6282] specifies the compression format for IPv6 datagrams on top of IEEE 802.15.4; therefore, this format is used for compression of IPv6 datagrams within PLC MAC frames. For situations when the PLC MAC MTU cannot support the 1280-octet IPv6 packet, the headers MUST be compressed according to the encoding formats specified in [RFC6282], including the Dispatch Header, the LOWPAN_IPHC, and the compression residue carried inline.
PLCのIPv6ヘッダー圧縮は[RFC6282]（[RFC4944]を更新）に基づいています。[RFC6282] IEEE 802.15.4の上にあるIPv6データグラムの圧縮形式を指定します。したがって、この形式は、PLC Macフレーム内のIPv6データグラムの圧縮に使用されます。PLC MAC MTUが1280-OCTET IPv6パケットをサポートできない状況では、ディスパッチヘッダー、LowPAN_IPHC、およびインラインで運ばれた圧縮滞在を含む[RFC6282]で指定されたエンコード形式に従ってヘッダーを圧縮する必要があります。
For IEEE 1901.2 and ITU-T G.9903, the IP header compression follows the instruction in [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 Section 3.1 of [RFC6282], which is illustrated as follows.
IEEE 1901.2およびITU-T G.9903の場合、IPヘッダー圧縮は[RFC6282]の命令に従います。ただし、16ビットではなく12ビットの短いアドレスを持っているため、IEEE 1901.1には追加の適応を考慮する必要があります。唯一の変更は、[RFC6282]のセクション3.1で「10」として設定されたときの「ソースアドレスモード」と「宛先アドレスモード」のセマンティクスです。これは、次のように示されています。
SAM: Source Address Mode:
SAM：ソースアドレスモード：
If SAC=0: Stateless compression
SAC = 0の場合：ステートレス圧縮
10:
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 inline, in which the first 4 bits are zero.
16ビット。アドレスの最初の112ビットは省略されています。最初の64ビットの値は、ゼロでパッド入りのリンクローカルプレフィックスです。次の64ビットは0000：00ff：fe00：0xxxです。ここで、0xxxは16ビットがインラインで運ばれ、最初の4ビットはゼロです。
If SAC=1: Stateful context-based compression
SAC = 1の場合：ステートフルなコンテキストベースの圧縮
10:
10：
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 the 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.
16ビット。アドレスは、コンテキスト情報を使用して導出され、16ビットがインラインで運ばれます。コンテキスト情報でカバーされているビットは常に使用されます。コンテキスト情報でカバーされていないIIDビットは、16ビットの短いアドレスと0000：00FF：00FF：fe00：0xxxで提供されるIIDの間のマッピングの対応するビットから直接取得されます。最初の4ビットはゼロです。残りのビットはゼロです。
DAM: Destination Address Mode:
ダム：宛先アドレスモード：
If M=0 and DAC=0: Stateless compression
m = 0およびdac = 0の場合：ステートレス圧縮
10:
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 inline, in which the first 4 bits are zero.
16ビット。アドレスの最初の112ビットは省略されています。最初の64ビットの値は、ゼロでパッド入りのリンクローカルプレフィックスです。次の64ビットは0000：00ff：fe00：0xxxです。ここで、0xxxは16ビットがインラインで運ばれ、最初の4ビットはゼロです。
If M=0 and DAC=1: Stateful context-based compression
m = 0およびdac = 1の場合：ステートフルなコンテキストベースの圧縮
10:
10：
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 the 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.
16ビット。アドレスは、コンテキスト情報を使用して導出され、16ビットがインラインで運ばれます。コンテキスト情報でカバーされているビットは常に使用されます。コンテキスト情報でカバーされていないIIDビットは、16ビットの短いアドレスと0000：00FF：00FF：fe00：0xxxで提供されるIIDの間のマッピングの対応するビットから直接取得されます。最初の4ビットはゼロです。残りのビットはゼロです。
The constrained PLC MAC layer provides the functions of fragmentation and reassembly. However, fragmentation and reassembly are still required at the adaptation layer if the MAC layer cannot support the minimum MTU demanded by IPv6, which is 1280 octets.
制約付きPLC MACレイヤーは、断片化と再組み立ての機能を提供します。ただし、MACレイヤーが1280オクテットであるIPv6が要求する最小MTUをサポートできない場合、適応層では断片化と再組み立てが必要です。
In IEEE 1901.1 and IEEE 1901.2, the MAC layer supports payloads as big as 2031 octets and 1576 octets, respectively. However, when the channel condition is noisy, smaller packets have a higher transmission success rate, and the operator can choose to configure smaller MTU at the MAC layer. If the configured MTU is smaller than 1280 octets, the fragmentation and reassembly defined in [RFC4944] MUST be used.
IEEE 1901.1およびIEEE 1901.2では、MACレイヤーはそれぞれ2031オクテットと1576オクテットのペイロードをサポートしています。ただし、チャネル条件が騒々しい場合、小さいパケットの伝送成功率が高く、オペレーターはMACレイヤーでより小さなMTUを構成することを選択できます。構成されたMTUが1280オクテットよりも小さい場合、[RFC4944]で定義されている断片化と再組み立てを使用する必要があります。
In ITU-T G.9903, the maximum MAC payload size is fixed to 400 octets, so to cope with the required MTU of 1280 octets by IPv6, fragmentation and reassembly at the 6lo adaptation layer MUST be provided as specified in [RFC4944].
ITU-T G.9903では、最大MACペイロードサイズは400オクテットに固定されているため、[RFC4944]で指定されているように、6LO適応層でのIPv6による1280オクテットの必要なMTUに対処するために、断片化と再組み立てを提供する必要があります。
[RFC4944] uses a 16-bit datagram tag to identify the fragments of the same IP packet. [RFC4963] specifies that at high data rates, the 16-bit IP identification field is not large enough to prevent frequent incorrectly assembled IP fragments. For constrained PLC, the data rate is much lower than the situation mentioned in [RFC4963]; thus, the 16-bit tag is sufficient to assemble the fragments correctly.
[RFC4944]は、16ビットデータグラムタグを使用して、同じIPパケットのフラグメントを識別します。[RFC4963]は、高いデータレートで、16ビットIP識別フィールドが頻繁に誤って組み立てられたIPフラグメントを防ぐのに十分な大きさではないことを指定しています。制約されたPLCの場合、データレートは[RFC4963]で言及されている状況よりもはるかに低いです。したがって、16ビットタグは、フラグメントを正しく組み立てるのに十分です。
The PLC network model can be simplified to two kinds of network devices: PAN Coordinator (PANC) and PLC device. The PANC is the primary coordinator of the PLC subnet and can be seen as a primary node; PLC devices are typically PLC meters and sensors. The address registration and DAD features can also be deployed on the PANC, for example, the 6LBR [RFC6775] or the routing registrar [RFC8505]. IPv6 over PLC networks are built as tree, mesh, or star topologies according to the use cases. Generally, each PLC network has one PANC. In some cases, the PLC network can have alternate coordinators to replace the PANC when the PANC leaves the network for some reason. Note that the PLC topologies in this section are based on logical connectivity, not physical links. The term "PLC subnet" refers to a multilink subnet, in which the PLC devices share the same address prefix.
PLCネットワークモデルは、PANコーディネーター（PANC）とPLCデバイスの2種類のネットワークデバイスに簡素化できます。PANCはPLCサブネットの主要なコーディネーターであり、プライマリノードと見なすことができます。PLCデバイスは通常、PLCメーターとセンサーです。アドレス登録とDADの機能は、6LBR [RFC6775]またはルーティングレジストラ[RFC8505]など、PANCに展開することもできます。PLCネットワークを介したIPv6は、ユースケースに従ってツリー、メッシュ、またはスタートポロジとして構築されています。一般に、各PLCネットワークには1つのパンクがあります。場合によっては、PLCネットワークには、何らかの理由でPANCがネットワークを離れるときにPANCを交換する代替コーディネーターを持つことができます。このセクションのPLCトポロジーは、物理的なリンクではなく論理的な接続に基づいていることに注意してください。「PLCサブネット」という用語は、PLCデバイスが同じアドレスプレフィックスを共有するMultiLink Subnetを指します。
The star topology is common in current PLC scenarios. In single-hop star topologies, communication at the link layer only takes place between a PLC device and a PANC. The PANC typically collects data (e.g., a meter reading) from the PLC devices and then concentrates and uploads the data through Ethernet or cellular networks (see Figure 5). The collected data is transmitted by the smart meters through PLC, aggregated by a concentrator, and sent to the utility and then to a Meter Data Management System for data storage, analysis, and billing. This topology has been widely applied in the deployment of smart meters, especially in apartment buildings.
Starトポロジーは、現在のPLCシナリオで一般的です。シングルホップスタートポロジーでは、リンクレイヤーでの通信は、PLCデバイスとパンクの間でのみ行われます。PANCは通常、PLCデバイスからデータ（メーターの読み取りなど）を収集し、イーサネットまたはセルラーネットワークを介してデータを集中およびアップロードします（図5を参照）。収集されたデータは、PLCを介してスマートメーターによって送信され、コンセントレーターによって集約され、ユーティリティに送られ、次にデータストレージ、分析、請求のためにメーターデータ管理システムに送信されます。このトポロジーは、特にアパートの建物でスマートメーターの展開に広く適用されています。
PLC Device PLC Device
\ / +---------
\ / /
\ / +
\ / |
PLC Device ------ PANC ===========+ Internet
/ \ |
/ \ +
/ \ \
/ \ +---------
PLC Device PLC Device
<---------------------->
PLC subnet (IPv6 over PLC)
Figure 5: PLC Star Network Connected to the Internet
図5：インターネットに接続されているPLCスターネットワーク
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 able to communicate with both sides. Device B in this case acts as both a PLC device and a Coordinator. For this scenario, the link-layer communications take place between device A and device B, and between device B and PANC. An example of a PLC tree network is depicted in Figure 6. This topology can be applied in smart street lighting, where the lights adjust the brightness to reduce energy consumption while sensors are deployed on the street lights to provide information such as light intensity, temperature, and humidity. The data-transmission distance in the street lighting scenario is normally above several kilometers; thus, a PLC tree network is required. A more sophisticated AMI network may also be constructed into the tree topology that is depicted in [RFC8036]. A tree topology is suitable for AMI scenarios that require large coverage but low density, e.g., the deployment of smart meters in rural areas. RPL is suitable for maintenance of a tree topology in which there is no need for communication directly between PAN devices.
ツリートポロジーは、デバイスAとPANCの間の距離がPLCでの制限を超えており、両側と通信できる別のデバイスBがある場合に役立ちます。この場合のデバイスBは、PLCデバイスとコーディネーターの両方として機能します。このシナリオでは、リンク層通信は、デバイスAとデバイスBの間、およびデバイスBとPANCの間で行われます。PLCツリーネットワークの例を図6に示します。このトポロジーはスマートストリート照明に適用できます。ここでは、ライトが明るさを調整してエネルギー消費を減らし、センサーが路上ライトに展開され、光強度、温度などの情報を提供することができます。、および湿度。路上照明シナリオのデータ移動距離は、通常数キロメートルを超えています。したがって、PLCツリーネットワークが必要です。[RFC8036]に描かれているより洗練されたAMIネットワークをツリートポロジーに構築することもできます。ツリートポロジは、大規模なカバレッジが必要ですが、密度が低いAMIシナリオに適しています。たとえば、農村部でのスマートメーターの展開です。RPLは、PANデバイス間で直接通信する必要がないツリートポロジのメンテナンスに適しています。
PLC Device
\ +---------
PLC Device A \ /
\ \ +
\ \ |
PLC Device B -- PANC ===========+ Internet
/ / |
/ / +
PLC Device---PLC Device / \
/ +---------
PLC Device---PLC Device
<------------------------->
PLC subnet (IPv6 over PLC)
Figure 6: PLC Tree Network Connected to the Internet
図6：インターネットに接続されているPLCツリーネットワーク
Mesh networking in PLC has many potential applications and has been studied for several years. By connecting all nodes with their neighbors in communication range (see Figure 7), a mesh topology dramatically enhances the communication efficiency and thus expands the size of PLC networks. A simple use case is the smart home scenario where the ON/OFF state of air conditioning is controlled by the state of home lights (ON/OFF) and doors (OPEN/CLOSE). AODV-RPL [AODV-RPL] enables direct communication between PLC devices, without being obliged to transmit frames through the PANC, which is a requirement often cited for the AMI infrastructure.
PLCのメッシュネットワーキングには多くの潜在的なアプリケーションがあり、数年間研究されています。すべてのノードを通信範囲内の近隣のノードと接続することにより（図7を参照）、メッシュトポロジは通信効率を劇的に向上させ、PLCネットワークのサイズを拡大します。単純なユースケースは、エアコンのオン/オフ状態がホームライトの状態（オン/オフ）とドア（オープン/クローズ）によって制御されるスマートホームシナリオです。AODV-RPL [AODV-RPL]は、PLCデバイス間の直接通信を可能にします。これは、AMIインフラストラクチャにしばしば引用される要件であるPANCを介してフレームを送信する義務があります。
PLC Device---PLC Device
/ \ / \ +---------
/ \ / \ /
/ \ / \ +
/ \ / \ |
PLC Device--PLC Device---PANC ===========+ Internet
\ / \ / |
\ / \ / +
\ / \ / \
\ / \ / +---------
PLC Device---PLC Device
<------------------------------->
PLC subnet (IPv6 over PLC)
Figure 7: PLC Mesh Network Connected to the Internet
図7：インターネットに接続されているPLCメッシュネットワーク
Constrained PLC networks are not managed in the same way as enterprise networks or carrier networks. Constrained PLC networks, like the other IoT networks, are designed to be self-organized and self-managed. The software or firmware is flashed into the devices before deployment by the vendor or operator. And during the deployment process, the devices are bootstrapped, and no extra configuration is needed to get the devices connected to each other. Once a device becomes offline, it goes back to the bootstrapping stage and tries to rejoin the network. The onboarding status of the devices and the topology of the PLC network can be visualized via the PANC. The recently formed IOTOPS WG in the IETF aims to identify the requirements in IoT network management, and operational practices will be published. Developers and operators of PLC networks should be able to learn operational experiences from this WG.
制約付きPLCネットワークは、エンタープライズネットワークやキャリアネットワークと同じように管理されていません。制約付きPLCネットワークは、他のIoTネットワークと同様に、自己組織化され、自己管理されるように設計されています。ソフトウェアまたはファームウェアは、ベンダーまたはオペレーターによって展開する前にデバイスにフラッシュされます。展開プロセス中、デバイスはブートストラップされており、デバイスを相互に接続するために追加の構成は必要ありません。デバイスがオフラインになると、ブートストラップステージに戻り、ネットワークに再び参加しようとします。デバイスのオンボーディングステータスとPLCネットワークのトポロジは、PANCを介して視覚化できます。IETFで最近形成されたIoTOPS WGは、IoTネットワーク管理の要件を特定することを目的としており、運用慣行が公開されます。PLCネットワークの開発者とオペレーターは、このWGから運用体験を学ぶことができるはずです。
This document has no IANA actions.
このドキュメントにはIANAアクションがありません。
Due to the high accessibility of power grids, PLC might be susceptible to eavesdropping within its communication coverage, e.g., one apartment tenant may have the chance to monitor the other smart meters in the same apartment building. Link-layer security mechanisms, such as payload encryption and device authentication, are designed in the PLC technologies mentioned in this document. Additionally, an on-path malicious PLC device could eavesdrop or modify packets sent through it if appropriate confidentiality and integrity mechanisms are not implemented.
電力グリッドのアクセスが高いため、PLCは通信カバレッジ内で盗聴を受けやすい可能性があります。たとえば、1つのアパートテナントは、同じアパートの建物の他のスマートメーターを監視する機会がある場合があります。ペイロード暗号化やデバイス認証などのリンク層セキュリティメカニズムは、このドキュメントに記載されているPLCテクノロジーで設計されています。さらに、適切な機密性と整合性メカニズムが実装されていない場合、パス上の悪意のあるPLCデバイスは、それを通して送信されたパケットを盗聴または変更できます。
Malicious PLC devices could paralyze the whole network via DoS attacks, e.g., keep joining and leaving the network frequently or sending multicast routing messages containing fake metrics. A device may also inadvertently join a wrong or even malicious network, exposing its data to malicious users. When communicating with a device outside the PLC network, the traffic has to go through the PANC. Thus, the PANC must be a trusted entity. Moreover, the PLC network must prevent malicious devices from joining the network. Thus, mutual authentication of a PLC network and a new device is important, and it can be conducted during the onboarding process of the new device. Methods include protocols such as the TLS/DTLS Profile [RFC7925] (exchanging pre-installed certificates over DTLS), the Constrained Join Protocol (CoJP) [RFC9031] (which uses pre-shared keys), and Zero-Touch Secure Join [ZEROTOUCH] (an IoT version of the Bootstrapping Remote Secure Key Infrastructure (BRSKI), which uses an Initial Device Identifier (IDevID) and a Manufacturer Authorized Signing Authority (MASA) service to facilitate authentication). It is also possible to use Extensible Authentication Protocol (EAP) methods such as the one defined in [RFC9140] via transports like Protocol for Carrying Authentication for Network Access (PANA) [RFC5191]. No specific mechanism is specified by this document, as an appropriate mechanism will depend upon deployment circumstances. In some cases, the PLC devices can be deployed in uncontrolled places, where the devices may be accessed physically and be compromised via key extraction. The compromised device may be still able to join in the network since its credentials are still valid. When group-shared symmetric keys are used in the network, the consequence is even more severe, i.e., the whole network or a large part of the network is at risk. Thus, in scenarios where physical attacks are considered to be relatively highly possible, per-device credentials SHOULD be used. Moreover, additional end-to-end security services are complementary to the network-side security mechanisms, e.g., if a device is compromised and has joined in the network, and then it claims itself as the PANC and tries to make the rest of the devices join its network. In this situation, the real PANC can send an alarm to the operator to acknowledge the risk. Other behavior-analysis mechanisms can be deployed to recognize the malicious PLC devices by inspecting the packets and the data.
悪意のあるPLCデバイスは、DOS攻撃を介してネットワーク全体を麻痺させる可能性があります。たとえば、ネットワークを頻繁に出し続けたり、偽のメトリックを含むマルチキャストルーティングメッセージを送信したりします。また、デバイスは不注意に間違ったネットワークまたは悪意のあるネットワークに参加し、そのデータを悪意のあるユーザーに公開する場合があります。PLCネットワークの外側のデバイスと通信する場合、トラフィックはPANCを通過する必要があります。したがって、パンクは信頼できるエンティティでなければなりません。さらに、PLCネットワークは、悪意のあるデバイスがネットワークに参加できないようにする必要があります。したがって、PLCネットワークと新しいデバイスの相互認証が重要であり、新しいデバイスのオンボーディングプロセス中に実行できます。方法には、TLS/DTLSプロファイル[RFC7925]（DTLSを介した事前にインストールされた証明書の交換）、制約付きの結合プロトコル（COJP）[RFC9031]（事前共有キーを使用）、およびゼロタッチセキュアJOIN [Zerotouchouch [Zerotouchoutooutouch]などのプロトコルが含まれます。]（初期デバイス識別子（IDEVID）を使用しているリモートセキュアなキーインフラストラクチャ（BRSKI）のブートストラップのIoTバージョンと、認証を促進するためのメーカー認定署名機関（MASA）サービス）。また、ネットワークアクセスのための認証を運ぶためのプロトコルなどのトランスポート（PANA）[RFC5191]を介して[RFC9140]で定義されているような拡張可能な認証プロトコル（EAP）メソッドを使用することも可能です。適切なメカニズムは展開の状況に依存するため、このドキュメントによって特定のメカニズムは指定されていません。場合によっては、PLCデバイスは制御されていない場所に展開できます。そこでは、デバイスに物理的にアクセスし、キー抽出により侵害される場合があります。妥協したデバイスは、その資格情報がまだ有効であるため、ネットワークに参加できる可能性があります。ネットワークでグループ共有対称キーを使用すると、結果はさらに深刻です。つまり、ネットワーク全体またはネットワークの大部分が危険にさらされています。したがって、物理的な攻撃が比較的非常に可能であると見なされるシナリオでは、デバイスごとの資格情報を使用する必要があります。さらに、追加のエンドツーエンドのセキュリティサービスは、ネットワーク側のセキュリティメカニズムを補完します。たとえば、デバイスが侵害され、ネットワークに結合された場合、それはパンクとして主張し、残りの部分を作成しようとします。デバイスはネットワークに参加します。この状況では、実際のパンクはリスクを認めるためにオペレーターにアラームを送ることができます。他の動作分析メカニズムを展開して、パケットとデータを検査することにより、悪意のあるPLCデバイスを認識できます。
IP addresses may be used to track devices on the Internet; such devices can often in turn be linked to individuals and their activities. Depending on the application and the actual use pattern, this may be undesirable. To impede tracking, globally unique and non-changing characteristics of IP addresses should be avoided, e.g., by frequently changing the global prefix and avoiding unique link-layer derived IIDs in addresses. [RFC8065] discusses the privacy threats when an IID is generated without sufficient entropy, including correlation of activities over time, location tracking, device-specific vulnerability exploitation, and address scanning. And an effective way to deal with these threats is to have enough entropy in the IID compared to the link lifetime. Consider a PLC network with 1024 devices and a link lifetime is 8 years, according to the formula in [RFC8065], an entropy of 40 bits is sufficient. Padding the short address (12 or 16 bits) to generate the IID of a routable IPv6 address in the public network may be vulnerable to deal with address scans. Thus, as suggested in Section 4.1, a hash function can be used to generate a 64-bit IID. When the version number of the PLC network is changed, the IPv6 addresses can be changed as well. Other schemes such as limited lease period in DHCPv6 [RFC8415], Cryptographically Generated Addresses (CGAs) [RFC3972], Temporary Address Extensions [RFC8981], Hash-Based Addresses (HBAs) [RFC5535], or semantically opaque addresses [RFC7217] SHOULD be used to enhance the IID privacy.
IPアドレスは、インターネット上のデバイスを追跡するために使用できます。このようなデバイスは、多くの場合、個人とその活動にリンクすることができます。アプリケーションと実際の使用パターンに応じて、これは望ましくない場合があります。追跡を妨げるために、グローバルなプレフィックスを頻繁に変更し、アドレスで一意のリンク層導出IIDを回避することにより、IPアドレスのグローバルにユニークで変化しない特性を避ける必要があります。[RFC8065]は、時間の経過に伴うアクティビティの相関、デバイス固有の脆弱性の搾取、アドレススキャンなど、十分なエントロピーなしでIIDが生成されたときにプライバシーの脅威について説明します。そして、これらの脅威に対処する効果的な方法は、リンクの寿命と比較してIIDに十分なエントロピーを持つことです。[RFC8065]の式によると、1024のデバイスを備えたPLCネットワークとリンク寿命は8年です。40ビットのエントロピーで十分です。パブリックネットワークでルーティング可能なIPv6アドレスのIIDを生成するために、短いアドレス（12または16ビット）をパディングすることは、アドレススキャンに対処するために脆弱になる場合があります。したがって、セクション4.1で示唆されているように、ハッシュ関数を使用して64ビットIIDを生成できます。PLCネットワークのバージョン番号が変更されると、IPv6アドレスも変更できます。DHCPV6 [RFC8415]の限られたリース期間、暗号化されたアドレス（CGAS）[RFC3972]、一時アドレス拡張[RFC8981]、ハッシュベースのアドレス（HBA）[RFC555555]、またはサミャンティックなオパークアドレス[RFC7217]などの他のスキームIIDプライバシーを強化するために使用されます。
[IEEE_1901.1]
IEEE, "IEEE Standard for Medium Frequency (less than 12
MHz) Power Line Communications for Smart Grid
Applications", DOI 10.1109/IEEESTD.2018.8360785, IEEE
Std 1901.1, May 2018,
<https://ieeexplore.ieee.org/document/8360785>.
[IEEE_1901.2]
IEEE, "IEEE Standard for Low-Frequency (less than 500 kHz)
Narrowband Power Line Communications for Smart Grid
Applications", DOI 10.1109/IEEESTD.2013.6679210, IEEE
Std 1901.2, December 2013,
<https://ieeexplore.ieee.org/document/6679210>.
[ITU-T_G.9903]
ITU-T, "Narrowband orthogonal frequency division
multiplexing power line communication transceivers for
G3-PLC networks", ITU-T Recommendation G.9903, August
2017, <https://www.itu.int/rec/T-REC-G.9903>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC2464] Crawford, M., "Transmission of IPv6 Packets over Ethernet
Networks", RFC 2464, DOI 10.17487/RFC2464, December 1998,
<https://www.rfc-editor.org/info/rfc2464>.
[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing
Architecture", RFC 4291, DOI 10.17487/RFC4291, February
2006, <https://www.rfc-editor.org/info/rfc4291>.
[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
"Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,
DOI 10.17487/RFC4861, September 2007,
<https://www.rfc-editor.org/info/rfc4861>.
[RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler,
"Transmission of IPv6 Packets over IEEE 802.15.4
Networks", RFC 4944, DOI 10.17487/RFC4944, September 2007,
<https://www.rfc-editor.org/info/rfc4944>.
[RFC6282] Hui, J., Ed. and P. Thubert, "Compression Format for IPv6
Datagrams over IEEE 802.15.4-Based Networks", RFC 6282,
DOI 10.17487/RFC6282, September 2011,
<https://www.rfc-editor.org/info/rfc6282>.
[RFC6550] Winter, T., Ed., Thubert, P., Ed., Brandt, A., Hui, J.,
Kelsey, R., Levis, P., Pister, K., Struik, R., Vasseur,
JP., and R. Alexander, "RPL: IPv6 Routing Protocol for
Low-Power and Lossy Networks", RFC 6550,
DOI 10.17487/RFC6550, March 2012,
<https://www.rfc-editor.org/info/rfc6550>.
[RFC6775] Shelby, Z., Ed., Chakrabarti, S., Nordmark, E., and C.
Bormann, "Neighbor Discovery Optimization for IPv6 over
Low-Power Wireless Personal Area Networks (6LoWPANs)",
RFC 6775, DOI 10.17487/RFC6775, November 2012,
<https://www.rfc-editor.org/info/rfc6775>.
[RFC7136] Carpenter, B. and S. Jiang, "Significance of IPv6
Interface Identifiers", RFC 7136, DOI 10.17487/RFC7136,
February 2014, <https://www.rfc-editor.org/info/rfc7136>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8505] Thubert, P., Ed., Nordmark, E., Chakrabarti, S., and C.
Perkins, "Registration Extensions for IPv6 over Low-Power
Wireless Personal Area Network (6LoWPAN) Neighbor
Discovery", RFC 8505, DOI 10.17487/RFC8505, November 2018,
<https://www.rfc-editor.org/info/rfc8505>.
[AODV-RPL] Perkins, C. E., Anand, S.V.R., Anamalamudi, S., and B.
Liu, "Supporting Asymmetric Links in Low Power Networks:
AODV-RPL", Work in Progress, Internet-Draft, draft-ietf-
roll-aodv-rpl-15, 30 September 2022,
<https://datatracker.ietf.org/doc/html/draft-ietf-roll-
aodv-rpl-15>.
[EUI-64] IEEE Standards Association, "Guidelines for Use of
Extended Unique Identifier (EUI), Organizationally Unique
Identifier (OUI), and Company ID (CID)", August 2017,
<https://standards.ieee.org/wp-
content/uploads/import/documents/tutorials/eui.pdf>.
[IEEE_1901.2a]
IEEE, "IEEE Standard for Low-Frequency (less than 500 kHz)
Narrowband Power Line Communications for Smart Grid
Applications - Amendment 1",
DOI 10.1109/IEEESTD.2013.6679210, IEEE Std 1901.2a,
October 2015,
<https://ieeexplore.ieee.org/document/7286946>.
[RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)",
RFC 3972, DOI 10.17487/RFC3972, March 2005,
<https://www.rfc-editor.org/info/rfc3972>.
[RFC4963] Heffner, J., Mathis, M., and B. Chandler, "IPv4 Reassembly
Errors at High Data Rates", RFC 4963,
DOI 10.17487/RFC4963, July 2007,
<https://www.rfc-editor.org/info/rfc4963>.
[RFC5191] Forsberg, D., Ohba, Y., Ed., Patil, B., Tschofenig, H.,
and A. Yegin, "Protocol for Carrying Authentication for
Network Access (PANA)", RFC 5191, DOI 10.17487/RFC5191,
May 2008, <https://www.rfc-editor.org/info/rfc5191>.
[RFC5535] Bagnulo, M., "Hash-Based Addresses (HBA)", RFC 5535,
DOI 10.17487/RFC5535, June 2009,
<https://www.rfc-editor.org/info/rfc5535>.
[RFC7217] Gont, F., "A Method for Generating Semantically Opaque
Interface Identifiers with IPv6 Stateless Address
Autoconfiguration (SLAAC)", RFC 7217,
DOI 10.17487/RFC7217, April 2014,
<https://www.rfc-editor.org/info/rfc7217>.
[RFC7925] Tschofenig, H., Ed. and T. Fossati, "Transport Layer
Security (TLS) / Datagram Transport Layer Security (DTLS)
Profiles for the Internet of Things", RFC 7925,
DOI 10.17487/RFC7925, July 2016,
<https://www.rfc-editor.org/info/rfc7925>.
[RFC7973] Droms, R. and P. Duffy, "Assignment of an Ethertype for
IPv6 with Low-Power Wireless Personal Area Network
(LoWPAN) Encapsulation", RFC 7973, DOI 10.17487/RFC7973,
November 2016, <https://www.rfc-editor.org/info/rfc7973>.
[RFC8036] Cam-Winget, N., Ed., Hui, J., and D. Popa, "Applicability
Statement for the Routing Protocol for Low-Power and Lossy
Networks (RPL) in Advanced Metering Infrastructure (AMI)
Networks", RFC 8036, DOI 10.17487/RFC8036, January 2017,
<https://www.rfc-editor.org/info/rfc8036>.
[RFC8065] Thaler, D., "Privacy Considerations for IPv6 Adaptation-
Layer Mechanisms", RFC 8065, DOI 10.17487/RFC8065,
February 2017, <https://www.rfc-editor.org/info/rfc8065>.
[RFC8415] Mrugalski, T., Siodelski, M., Volz, B., Yourtchenko, A.,
Richardson, M., Jiang, S., Lemon, T., and T. Winters,
"Dynamic Host Configuration Protocol for IPv6 (DHCPv6)",
RFC 8415, DOI 10.17487/RFC8415, November 2018,
<https://www.rfc-editor.org/info/rfc8415>.
[RFC8981] Gont, F., Krishnan, S., Narten, T., and R. Draves,
"Temporary Address Extensions for Stateless Address
Autoconfiguration in IPv6", RFC 8981,
DOI 10.17487/RFC8981, February 2021,
<https://www.rfc-editor.org/info/rfc8981>.
[RFC9010] Thubert, P., Ed. and M. Richardson, "Routing for RPL
(Routing Protocol for Low-Power and Lossy Networks)
Leaves", RFC 9010, DOI 10.17487/RFC9010, April 2021,
<https://www.rfc-editor.org/info/rfc9010>.
[RFC9031] Vučinić, M., Ed., Simon, J., Pister, K., and M.
Richardson, "Constrained Join Protocol (CoJP) for 6TiSCH",
RFC 9031, DOI 10.17487/RFC9031, May 2021,
<https://www.rfc-editor.org/info/rfc9031>.
[RFC9140] Aura, T., Sethi, M., and A. Peltonen, "Nimble Out-of-Band
Authentication for EAP (EAP-NOOB)", RFC 9140,
DOI 10.17487/RFC9140, December 2021,
<https://www.rfc-editor.org/info/rfc9140>.
[SCENA] Cano, C., Pittolo, A., Malone, D., Lampe, L., Tonello, A.,
and A. Dabak, "State of the Art in Power Line
Communications: From the Applications to the Medium", IEEE
Journal on Selected Areas in Communications, Volume 34,
Issue 7, DOI 10.1109/JSAC.2016.2566018, July 2016,
<https://ieeexplore.ieee.org/document/7467440>.
[ZEROTOUCH]
Richardson, M., "6tisch Zero-Touch Secure Join protocol",
Work in Progress, Internet-Draft, draft-ietf-6tisch-
dtsecurity-zerotouch-join-04, 8 July 2019,
<https://datatracker.ietf.org/doc/html/draft-ietf-6tisch-
dtsecurity-zerotouch-join-04>.
We gratefully acknowledge suggestions from the members of the IETF 6lo Working Group. Great thanks to Samita Chakrabarti and Gabriel Montenegro for their feedback and support in connecting the IEEE and ITU-T sides. The authors thank Scott Mansfield, Ralph Droms, and Pat Kinney for their guidance in the liaison process. The authors wish to thank Stefano Galli, Thierry Lys, Yizhou Li, Yuefeng Wu, and Michael Richardson for their valuable comments and contributions. The authors wish to thank Carles Gomez for shepherding this document. The authors also thank Paolo Volpato for delivering the presentation at IETF 113. Sincere acknowledgements to the valuable comments from the following reviewers: Dave Thaler, Dan Romascanu, Murray Kucherawy, Benjamin Kaduk, Alvaro Retana, Éric Vyncke, Meral Shirazipour, Roman Danyliw, and Lars Eggert.
IETF 6loワーキンググループのメンバーからの提案に感謝します。IEEEとITU-Tの側面をつなぐフィードバックとサポートをしてくれたサミタチャクラバルティとガブリエルモンテネグロに感謝します。著者は、スコット・マンスフィールド、ラルフ・ドロムズ、パット・キニーにリエゾンプロセスのガイダンスに感謝します。著者は、貴重なコメントと貢献について、Stefano Galli、Thierry Lys、Yizhou Li、Yuefeng Wu、Michael Richardsonに感謝したいと考えています。著者は、この文書を羊飼いしてくれたCarles Gomezに感謝したいと考えています。著者はまた、IETF 113でプレゼンテーションを提供してくれたPaolo Volpatoに感謝します。次のレビュアーからの貴重なコメントに対する誠実な謝辞：Dave Thaler、Dave Thaler、Dan Romascanu、Murray Kucherawy、Benjamin Kaduk、Alvaro Retana、Eric Vyncke、Meral Shirazipour、Roman Danyliwなどラース・エガート。
Jianqiang Hou
Huawei Technologies
101 Software Avenue,
Nanjing
210012
China
Email: houjianqiang@huawei.com
Bing Liu
Huawei Technologies
Haidian District
No. 156 Beiqing Rd.
Beijing
100095
China
Email: remy.liubing@huawei.com
Yong-Geun Hong
Daejeon University
Dong-gu
62 Daehak-ro
Daejeon
34520
Republic of Korea
Email: yonggeun.hong@gmail.com
Xiaojun Tang
State Grid Electric Power Research Institute
19 Chengxin Avenue
Nanjing
211106
China
Email: itc@sgepri.sgcc.com.cn
Charles E. Perkins
Lupin Lodge
Email: charliep@computer.org