6Lo Working Group J. Hou Internet-Draft B. Liu Intended status: Standards Track Huawei Technologies Expires: September 10, 2020 Y-G. Hong ETRI X. Tang SGEPRI C. Perkins March 9, 2020 Transmission of IPv6 Packets over PLC Networks draft-ietf-6lo-plc-02 Abstract Power Line Communication (PLC), namely using the electric-power lines for indoor and outdoor communications, has been widely applied to support Advanced Metering Infrastructure (AMI), especially smart meters for electricity. The inherent advantage of existing electricity infrastructure facilitates the expansion of PLC deployments, and 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 ITU-T G.9903, IEEE 1901.1 and IEEE 1901.2. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on September 10, 2020. Copyright Notice Copyright (c) 2020 IETF Trust and the persons identified as the document authors. All rights reserved. Hou, et al. Expires September 10, 2020 [Page 1] Internet-Draft IPv6 over PLC March 2020 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 Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Requirements Notation and Terminology . . . . . . . . . . . . 3 3. Overview of PLC . . . . . . . . . . . . . . . . . . . . . . . 4 3.1. Protocol Stack . . . . . . . . . . . . . . . . . . . . . 5 3.2. Addressing Modes . . . . . . . . . . . . . . . . . . . . 6 3.3. Maximum Transmission Unit . . . . . . . . . . . . . . . . 6 3.4. Routing Protocol . . . . . . . . . . . . . . . . . . . . 6 4. IPv6 over PLC . . . . . . . . . . . . . . . . . . . . . . . . 7 4.1. Stateless Address Autoconfiguration . . . . . . . . . . . 7 4.2. IPv6 Link Local Address . . . . . . . . . . . . . . . . . 8 4.3. Unicast Address Mapping . . . . . . . . . . . . . . . . . 8 4.3.1. Unicast Address Mapping for IEEE 1901.1 . . . . . . . 8 4.3.2. Unicast Address Mapping for IEEE 1901.2 and ITU-T G.9903 . . . . . . . . . . . . . . . . . . . . . . . 9 4.4. Neighbor Discovery . . . . . . . . . . . . . . . . . . . 10 4.5. Header Compression . . . . . . . . . . . . . . . . . . . 11 4.6. Fragmentation and Reassembly . . . . . . . . . . . . . . 11 5. Internet Connectivity Scenarios and Topologies . . . . . . . 12 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 7. Security Consideration . . . . . . . . . . . . . . . . . . . 14 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 15 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 9.1. Normative References . . . . . . . . . . . . . . . . . . 15 9.2. Informative References . . . . . . . . . . . . . . . . . 16 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18 1. Introduction The idea of using power lines for both electricity supply and communication can be traced back to the beginning of the last century. With the advantage of existing power grid, Power Line Communication (PLC) is a good candidate for supporting various service scenarios such as in houses and offices, in trains and vehicles, in smart grid and advanced metering infrastructure (AMI). The data acquisition devices in these scenarios share common features Hou, et al. Expires September 10, 2020 [Page 2] Internet-Draft IPv6 over PLC March 2020 such as fixed position, large quantity, low data rate and low power consumption. Although PLC technology has evolved over several decades, it has not been fully adapted for IPv6 based constrained networks. The 6lo related scenarios lie in the low voltage PLC networks with most applications in the area of Advanced Metering Infrastructure (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 efficent address auto-configuration. A comparison among various existing PLC standards is provided to facilitate the selection of the most applicable standard in particular scenarios. This specification provides a brief overview of PLC technologies. Some of them have LLN characteristics, i.e. limited power consumption, memory and processing resources. This specification is focused on the transmission of IPv6 packets over those "constrained" PLC networks. The general approach is to adapt elements of the 6LoWPAN specifications [RFC4944], [RFC6282], and [RFC6775] to constrained PLC networks. Compared to [I-D.popa-6lo-6loplc-ipv6-over-ieee19012-networks], this document provides a structured and greatly expanded specification of an adaptation layer for IPv6 over PLC (6LoPLC) networks. 2. Requirements Notation and Terminology 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 [RFC2119]. This document often uses the following acronyms and terminologies: 6LoWPAN: IPv6 over Low-Power Wireless Personal Area Network AMI: Advanced Metering Infrastructure BBPLC: Broadband Power Line Communication CID: Context ID Coordinator: A device capable of relaying messages. DAD: Duplicate Address Detection PAN device: An entity follows the PLC standards and implements the protocol stack described in this draft. Hou, et al. Expires September 10, 2020 [Page 3] Internet-Draft IPv6 over PLC March 2020 EV: Electric Vehicle IID: IPv6 Interface Identifier IPHC: IP Header Compression LAN: Local Area Network MSDU: MAC Service Data Unit MTU: Maximum Transmission Unit NBPLC: Narrowband Power Line Communication OFDM: Orthogonal Frequency Division Multiplexing PANC: PAN Coordinator, a coordinator which also acts as the primary controller of a PAN. PLC: Power Line Communication PSDU: PHY Service Data Unit RPL: IPv6 Routing Protocol for Low-Power and Lossy Networks RA: Router Advertisement WAN: Wide Area Network The terminology used in this draft is aligned with IEEE 1901.2 +-----------------+---------------------+----------------------+ | IEEE 1901.2 | IEEE 1901.1 | ITU-T G.9903 | +-----------------+---------------------+----------------------+ | PAN Coordinator | Central Coordinator | PAN Coordinator | | | | | | Coordinator | Proxy Coordinator | Full-function device | | | | | | Device | Station | PAN Device | +-----------------+---------------------+----------------------+ Table 1: Terminology Mapping between PLC standards 3. Overview of PLC PLC technology enables convenient two-way communications for home users and utility companies to monitor and control electric plugged devices such as electricity meters and street lights. Due to the Hou, et al. Expires September 10, 2020 [Page 4] Internet-Draft IPv6 over PLC March 2020 large range of communication frequencies, PLC is generally classified into two categories: Narrowband PLC (NBPLC) for automation of sensors (which have low frequency band and low power cost), and Broadband PLC (BBPLC) for home and industry networking applications. Various standards have been addressed on the MAC and PHY layers for this communication technology, e.g. BBPLC (1.8-250 MHz) including IEEE 1901 and ITU-T G.hn, and NBPLC (3-500 kHz) including ITU-T G.9902 (G.hnem), ITU-T G.9903 (G3-PLC) [ITU-T_G.9903], ITU-T G.9904 (PRIME), IEEE 1901.2 [IEEE_1901.2] (combination of G3-PLC and PRIME PLC) and IEEE 1901.2a [IEEE_1901.2a] (an amendment to IEEE 1901.2). Moreover, recently a new PLC standard IEEE 1901.1 [IEEE_1901.1], which aims at the medium frequency band less than 12 MHz, has been 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. Currently, this specification is focused on IEEE 1901.1, IEEE 1901.2 and ITU-T G.9903. 3.1. Protocol Stack The protocol stack for IPv6 over PLC is illustrated in Figure 1. The PLC MAC/PHY layer corresponds to 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. +----------------------------------------+ | Application Layer | +----------------------------------------+ | TCP/UDP | +----------------------------------------+ | | | IPv6 | | | +----------------------------------------+ | Adaptation layer for IPv6 over PLC | +----------------------------------------+ | PLC MAC Layer | +----------------------------------------+ | PLC PHY Layer | +----------------------------------------+ Figure 1: PLC Protocol Stack Hou, et al. Expires September 10, 2020 [Page 5] Internet-Draft IPv6 over PLC March 2020 3.2. Addressing Modes Each PLC device has a globally unique long address of 48-bit ([IEEE_1901.1]) or 64-bit ([IEEE_1901.2], [ITU-T_G.9903]) and a short address of 12-bit ([IEEE_1901.1]) or 16-bit ([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. 3.3. Maximum Transmission Unit 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 MTU lower than this limit, fragmentation and reassembly at the adaptation layer are required. The IEEE 1901.1 MAC supports upper layer packets up to 2031 octets. The IEEE 1901.2 MAC layer supports the MTU of 1576 octets (the original value of 1280 bytes was updated in 2015 [IEEE_1901.2a]). Though fragmentation and reassembly are not needed in these two technologies, other 6lo functions like header compression are still applicable and useful, particularly in high-noise communication environments. The MTU for ITU-T G.9903 is 400 octets, insufficient for supporting IPv6's MTU. For this reason, fragmentation and reassembly as per [RFC4944] MUST be enabled for G.9903-based networks. 3.4. Routing Protocol Routing protocols suitable for use in PLC networks include: o RPL (Routing Protocol for Low-Power and Lossy Networks) [RFC6550] is a layer 3 routing protocol. AODV-RPL [I-D.ietf-roll-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 L3 routing protocol for parent selection. For IPv6-addressable PLC networks, a layer-3 routing protocol such as RPL and/or AODV-RPL SHOULD be supported in the standard. o IEEE 1901.1 supports L2 routing. Each PLC node maintains a L2 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 Hou, et al. Expires September 10, 2020 [Page 6] Internet-Draft IPv6 over PLC March 2020 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. o LOADng 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. 4. IPv6 over PLC 6LoWPAN standards [RFC4944], [RFC6775], and [RFC6282] provides useful functionality including link-local IPv6 addresses, stateless address auto-configuration, neighbor discovery and header compression. However, due to the different characteristics of the PLC media, the 6LoWPAN adaptation layer cannot perfectly fulfill the requirements. Besides, some of the features like fragmentation and reassembly are redudant to some PLC technologies. These considerations suggest the need for a dedicated adaptation layer for PLC, which is detailed in the following subsections. 4.1. Stateless Address Autoconfiguration 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. 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 Interface ID by inserting 0xFFFE at the fourth and fifth octets as specified in [RFC2464]. The IPv6 IID is derived from the 64-bit Interface ID by inverting the U/L bit [RFC4291]. 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. Then, the 64-bit Interface ID MUST be derived by inserting 16-bit 0xFFFE into as follows: 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 24-bit NID (Network IDentifier, YYYYYY), 12 zero bits and a 12-bit TEI (Terminal Equipment Identifier, XXX). The 64-bit Interface ID MUST be derived by inserting 16-bit 0xFFFE into this 48-bit pseudo-address as follows: YYYY:YYFF:FE00:0XXX Hou, et al. Expires September 10, 2020 [Page 7] Internet-Draft IPv6 over PLC March 2020 Since the derived Interface ID is not global, the "Universal/Local" (U/L) bit (7th bit) and the Individual/Group bit (8th bit) MUST both be set to zero. In order to avoid any ambiguity in the derived Interface ID, these two bits MUST NOT be used to generate the PANID (for IEEE 1901.2 and ITU-T G.9903) or NID (for IEEE 1901.1). In other words, the PANID or NID MUST always be chosen so that these bits are zeros. For privacy reasons, the IID derived by the MAC address SHOULD only be used for link-local address configuration. A PLC host SHOULD use the IID derived by the link-layer short address to configure the IPv6 address used for communication with the public network; otherwise, the host's MAC address is exposed. 4.2. IPv6 Link Local Address 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). 10 bits 54 bits 64 bits +----------+-----------------------+----------------------------+ |1111111010| (zeros) | Interface Identifier | +----------+-----------------------+----------------------------+ Figure 2: IPv6 Link Local Address for a PLC interface 4.3. Unicast Address Mapping 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. The resolution is realized by the NCEs (neighbor cache entry) 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. 4.3.1. Unicast Address Mapping for IEEE 1901.1 The Source/Target Link-layer Address options for IEEE_1901.1 used in the Neighbor Solicitation and Neighbor Advertisement have the following form. Hou, et al. Expires September 10, 2020 [Page 8] Internet-Draft IPv6 over PLC March 2020 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 Option fields: Type: 1 for Source Link-layer Address and 2 for Target Link-layer Address. 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. NID: 24-bit Network IDentifier Padding: 12 zero bits TEI: 12-bit Terminal Equipment Identifier In order to avoid the possibility of duplicated IPv6 addresses, the value of the NID MUST be chosen so that the 7th and 8th bits of the first byte of the NID are both zero. 4.3.2. Unicast Address Mapping for IEEE 1901.2 and ITU-T G.9903 The Source/Target Link-layer Address options for IEEE_1901.2 and ITU-T G.9903 used in the Neighbor Solicitation and Neighbor Advertisement have the following form. 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 Option fields: Hou, et al. Expires September 10, 2020 [Page 9] Internet-Draft IPv6 over PLC March 2020 Type: 1 for Source Link-layer Address and 2 for Target Link-layer Address. 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. PAN ID: 16-bit PAN IDentifier Padding: 16 zero bits Short Address: 16-bit short address In order to avoid the possibility of duplicated IPv6 addresses, the value of the PAN ID MUST be chosen so that the 7th and 8th bits of the first byte of the PAN ID are both zero. 4.4. Neighbor Discovery Neighbor discovery procedures for 6LoWPAN networks are described in Neighbor Discovery Optimization for 6LoWPANs [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. For IPv6 address prefix dissemination, Router Solicitations (RS) and Router Advertisements (RA) MAY be used as per [RFC6775]. If the PLC network uses route-over mesh, the IPv6 prefix MAY be disseminated by the layer 3 routing protocol, such as RPL which includes the prefix in the DIO message. In this case, the prefix information option (PIO) MUST NOT be included in the Router Advertisement. For context information dissemination, Router Advertisements (RA) 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 compression. For address registration in route-over mode, a PLC device MUST register its addresses by sending unicast link-local Neighbor Solicitation to the 6LR. If the registered address is link-local, the 6LR SHOULD NOT further register it to the registrar (6LBR, 6BBR). Otherwise, the address MUST be registered via an ARO or EARO included in the DAR ([RFC6775]) or EDAR ([RFC8505]) messages. For RFC8505 compliant PLC devices, the 'R' flag in the EARO MUST be set when sending Neighbor Solicitaitons in order to extract the status information in the replied Neighbor Advertisements from the 6LR. If DHCPv6 is used to assign addresses or the IPv6 address is derived by unique long or short link layer address, Duplicate Address Detection Hou, et al. Expires September 10, 2020 [Page 10] Internet-Draft IPv6 over PLC March 2020 (DAD) MUST NOT be utilized. Otherwise, the DAD MUST be performed at the 6LBR (as per [RFC6775]) or proxied by the routing registrar (as per [RFC8505]). The registration status is feedbacked via the DAC or EDAC message from the 6LBR and the Neighbor Advertisement (NA) from the 6LR. For address registration in mesh-under mode, since all the PLC devices are the link-local neighbors to the 6LBR, DAR/DAC or EDAR/ EDAC messages are not required. A PLC device MUST register its addresses by sending the unicast NS message with an ARO or EARO. The registration status is feedbacked via the NA message from the 6LBR. 4.5. Header Compression The compression of IPv6 datagrams within PLC MAC frames refers to [RFC6282], which updates [RFC4944]. Header compression as defined in [RFC6282] which specifies the compression format for IPv6 datagrams on top of IEEE 802.15.4, is included in this document as 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 [RFC6282] encoding formats. 4.6. Fragmentation and Reassembly PLC differs from other wired technologies in that the communication medium is not shielded; thus, to successfully transmit data through power lines, PLC Data Link layer provides the function of segmentation and reassembly. A Segment Control Field is defined in the MAC frame header regardless of whether segmentation is required. The number of data octets of the PHY payload can change dynamically based on channel conditions, thus the MAC payload segmentation in the MAC sublayer is enabled and guarantees a reliable one-hop data transmission. Fragmentation and reassembly is still required at the adaptation layer, if the MAC layer cannot support the minimum MTU demanded by IPv6, which is 1280 octets. In IEEE 1901.1 and IEEE 1901.2, since the MAC layer supports payloads of 2031 octets and 1576 octets respectively, fragmentation is not needed for IPv6 packet transmission. The fragmentation and reassembly defined in [RFC4944] SHOULD NOT be used in the 6lo adaptation layer of IEEE 1901.2. 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 6lo adaptation layer MUST be provided referring to [RFC4944]. Hou, et al. Expires September 10, 2020 [Page 11] Internet-Draft IPv6 over PLC March 2020 5. Internet Connectivity Scenarios and Topologies The network model can be simplified to two kinds of network devices: PAN Coordinator (PANC) and PAN Device. The PANC is the primary coordinator of the PLC subnet and can be seen as a master node; PAN Devices are typically PLC meters and sensors. The PANC also serves as the Routing Registrar for proxy registration and DAD procedures, making use of the updated registration procedures in [RFC8505]. IPv6 over PLC networks are built as tree, mesh or star according to the use cases. Every network requires at least one PANC to communicate with each PAN Device. Note that the PLC topologies in this section are based on logical connectivity, not physical links. The star topology is common in current PLC scenarios. In single-hop star topologies, communication at the link layer only takes place between a PAN Device and a PANC. The PANC typically collects data (e.g. a meter reading) from the PAN devices, and then concentrates and uploads the data through Ethernet or LPWAN (see Figure 5). The collected data is transmitted by the smart meters through PLC, aggregated by a concentrator, 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. PAN Device PAN Device \ / +--------- \ / / \ / + \ / | PAN Device ------ PANC ===========+ Internet / \ | / \ + / \ \ / \ +--------- PAN Device PAN Device <----------------------> PLC subnet (IPv6 over PLC) Figure 5: PLC Star Network connected to the Internet A tree topology is useful when the distance between a device A and 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 both as a PAN 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 PLC tree network is depicted in Figure 6. This topology can be applied in the smart Hou, et al. Expires September 10, 2020 [Page 12] Internet-Draft IPv6 over PLC March 2020 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, humidity. Data transmission distance in the street lighting scenario is normally above several kilometers thus the PLC tree network is required. A more sophisticated AMI network may also be constructed into the tree topology which 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. PAN Device \ +--------- PAN Device \ / \ \ + \ \ | PAN Device -- PANC ===========+ Internet / / | / / + PAN Device---PAN Device / \ / +--------- PAN Device---PAN Device <-------------------------> PLC subnet (IPv6 over PLC) Figure 6: PLC Tree Network connected to the Internet Mesh networking in PLC is of great potential applications and has been studied for several years. By connecting all nodes with their neighbors in communication range (see Figure 7), 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 enables direct PAN device to PAN device communication, without being obliged to transmit frames through the PANC, which is a requirement often cited for AMI infrastructure. Hou, et al. Expires September 10, 2020 [Page 13] Internet-Draft IPv6 over PLC March 2020 PAN Device---PAN Device / \ / \ +--------- / \ / \ / / \ / \ + / \ / \ | PAN Device--PAN Device---PANC ===========+ Internet \ / \ / | \ / \ / + \ / \ / \ \ / \ / +--------- PAN Device---PAN Device <-------------------------------> PLC subnet (IPv6 over PLC) Figure 7: PLC Mesh Network connected to the Internet 6. IANA Considerations There are no IANA considerations related to this document. 7. Security Consideration Due to the high accessibility of power grid, 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. For security consideration, link layer security is guaranteed in every PLC technology. Malicious PLC devices could paralyze the whole network via DOS attacks, e.g., keep joining and leaving the network frequently, or multicast routing messages containing fake metrics. The security can be enhanced by using DTLS to authenticate a PLC device when it enrolles itself. If the PLC device is not direct neighbor to the PANC, where the authenticate is conducted, another PLC device which has joined the network can act as a proxy to help exchange the authenticate messages. The key used for encryption can also be negociated via DTLS. IP addresses may be used to track devices on the Internet; such devices can 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. [RFC3315], [RFC3972], [RFC4941], [RFC5535], [RFC7217], and [RFC8065] provide valuable information for Hou, et al. Expires September 10, 2020 [Page 14] Internet-Draft IPv6 over PLC March 2020 IID formation with improved privacy, and are RECOMMENDED for IPv6 networks. 8. Acknowledgements 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. Authors thank Scott Mansfield, Ralph Droms, Pat Kinney for their guidance in the liaison process. Authors wish to thank Stefano Galli, Thierry Lys, Yizhou Li and Yuefeng Wu for their valuable comments and contributions. 9. References 9.1. Normative References [IEEE_1901.1] IEEE-SA Standards Board, "Standard for Medium Frequency (less than 15 MHz) Power Line Communications for Smart Grid Applications", IEEE 1901.1, May 2018, . [IEEE_1901.2] IEEE-SA Standards Board, "IEEE Standard for Low-Frequency (less than 500 kHz) Narrowband Power Line Communications for Smart Grid Applications", IEEE 1901.2, October 2013, . [ITU-T_G.9903] International Telecommunication Union, "Narrowband orthogonal frequency division multiplexing power line communication transceivers for G3-PLC networks", ITU-T G.9903, February 2014, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC2464] Crawford, M., "Transmission of IPv6 Packets over Ethernet Networks", RFC 2464, DOI 10.17487/RFC2464, December 1998, . Hou, et al. Expires September 10, 2020 [Page 15] Internet-Draft IPv6 over PLC March 2020 [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, . [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, . [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, . [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, . [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, . [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, . 9.2. Informative References [I-D.ietf-roll-aodv-rpl] Anamalamudi, S., Zhang, M., Perkins, C., Anand, S., and B. Liu, "Asymmetric AODV-P2P-RPL in Low-Power and Lossy Networks (LLNs)", draft-ietf-roll-aodv-rpl-07 (work in progress), April 2019. [I-D.popa-6lo-6loplc-ipv6-over-ieee19012-networks] Popa, D. and J. Hui, "6LoPLC: Transmission of IPv6 Packets over IEEE 1901.2 Narrowband Powerline Communication Networks", draft-popa-6lo-6loplc-ipv6-over- ieee19012-networks-00 (work in progress), March 2014. Hou, et al. Expires September 10, 2020 [Page 16] Internet-Draft IPv6 over PLC March 2020 [IEEE_1901.2a] IEEE-SA Standards Board, "IEEE Standard for Low-Frequency (less than 500 kHz) Narrowband Power Line Communications for Smart Grid Applications - Amendment 1", IEEE 1901.2a, September 2015, . [RFC3315] Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins, C., and M. Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3315, DOI 10.17487/RFC3315, July 2003, . [RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)", RFC 3972, DOI 10.17487/RFC3972, March 2005, . [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 4291, DOI 10.17487/RFC4291, February 2006, . [RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy Extensions for Stateless Address Autoconfiguration in IPv6", RFC 4941, DOI 10.17487/RFC4941, September 2007, . [RFC5535] Bagnulo, M., "Hash-Based Addresses (HBA)", RFC 5535, DOI 10.17487/RFC5535, June 2009, . [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, . [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, . [RFC8065] Thaler, D., "Privacy Considerations for IPv6 Adaptation- Layer Mechanisms", RFC 8065, DOI 10.17487/RFC8065, February 2017, . Hou, et al. Expires September 10, 2020 [Page 17] Internet-Draft IPv6 over PLC March 2020 Authors' Addresses Jianqiang Hou Huawei Technologies 101 Software Avenue, Nanjing 210012 China Email: houjianqiang@huawei.com Bing Liu Huawei Technologies No. 156 Beiqing Rd. Haidian District, Beijing 100095 China Email: remy.liubing@huawei.com Yong-Geun Hong Electronics and Telecommunications Research Institute 161 Gajeong-Dong Yuseung-Gu Daejeon 305-700 Korea Email: yghong@etri.re.kr Xiaojun Tang State Grid Electric Power Research Institute 19 Chengxin Avenue Nanjing 211106 China Email: itc@sgepri.sgcc.com.cn Charles E. Perkins Email: charliep@computer.org Hou, et al. Expires September 10, 2020 [Page 18]