6Lo Working Group J. Hou Internet-Draft Huawei Technologies Intended Status: Standards Track Y-G. Hong Expires: June 14, 2018 ETRI X. Tang SGEPRI December 11, 2017 Transmission of IPv6 Packets over PLC Networks draft-hou-6lo-plc-03 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 the 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. As part of this technology, Narrowband PLC (NBPLC) is focused on the low- bandwidth and low-power scenarios that includes current standards such as ITU-T G.9903, IEEE 1901.2 and IEEE 1901.2a. This document describes how IPv6 packets are transported over constrained PLC networks. Status of this Memo This Internet-Draft is submitted to IETF 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 http://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 June 14, 2018. Copyright Notice Copyright (c) 2017 IETF Trust and the persons identified as the document authors. All rights reserved. Hou, et al Expires June 14, 2018 [Page 1] INTERNET DRAFT IPv6 over PLC December 11, 2017 This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://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 4. Specification of IPv6 over Narrowband PLC . . . . . . . . . . 6 4.1. Stateless Address Autoconfiguration . . . . . . . . . . . 6 4.2. IPv6 Link Local Address . . . . . . . . . . . . . . . . . 7 4.3. Unicast Address Mapping . . . . . . . . . . . . . . . . . 7 4.4. Neighbor Discovery . . . . . . . . . . . . . . . . . . . . 8 4.5. Header Compression . . . . . . . . . . . . . . . . . . . . 8 4.6. Fragmentation and Reassembly . . . . . . . . . . . . . . . 8 4.7. Extension at 6lo Adaptation Layer . . . . . . . . . . . . 9 5. Internet Connectivity Scenarios and Topologies . . . . . . . . 10 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 7. Security Consideration . . . . . . . . . . . . . . . . . . . . 13 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 9.1. Normative References . . . . . . . . . . . . . . . . . . . 13 9.2. Informative References . . . . . . . . . . . . . . . . . . 14 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15 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, 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). Such applications cover the smart meters for electricity, gas and water that share the common features like fixed position, large quantity, low data rate, and long life time. Although PLC technology has an evolution history of several decades, Hou, et al Expires June 14, 2018 [Page 2] INTERNET DRAFT IPv6 over PLC December 11, 2017 the adaptation of PLC for IPv6 based constrained networks is not fully developed. The 6lo related scenarios lie in the low voltage PLC networks with most applications in the area of Advanced Metering Infrastructure, Vehicle-to-Grid communications, in-home energy management and smart street lighting. It is of great importance to deploy IPv6 for PLC devices for its large address space and quick addressing. In addition, due to various existing PLC standards, a comparison among them is needed to facilitate the selection of the most applicable PLC standard in certain using scenarios. The following sections provide a brief overview of PLC, then describe transmission of IPv6 packets over PLC networks. The general approach is to adapt elements of the 6LoWPAN specifications [RFC4944], [RFC6282], and [RFC6775] to constrained PLC networks. Similar 6LoPLC adaptation layer was previously proposed in [draft-popa-6lo-6loplc], however, with the same purpose, this document provides more updated, structured and instructive information for the deployment of IPv6 over PLC 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]. Below are the terms used in this document: 6LoWPAN: IPv6 over Low-Power Wireless Personal Area Network AMI: Advanced Metering Infrastructure BBPLC: Broadband Power Line Communication CID: Context ID EV: Electric Vehicle HDPLC: High Definition Power Line Communication IID: Interface Identifier IPHC: IP Header Compression LAN: Local Area Network LOADng: Lightweight On-demand Ad-hoc Distance-vector Routing Protocol Next Generation Hou, et al Expires June 14, 2018 [Page 3] INTERNET DRAFT IPv6 over PLC December 11, 2017 MSDU: MAC Service Data Unit MTU: Maximum Transmission Unit NBPLC: Narrowband Power Line Communication OFDM: Orthogonal Frequency Division Multiplexing PCO: PAN Coordinator 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 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 large range of communication frequencies, PLC is generally classified into two categories: Narrowband PLC (NBPLC) for automation of sensors, 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 IEEE 1901.2, ITU-T G.9902 (G.hnem), ITU-T G.9903 (G3-PLC) and ITU-T G.9904 (PRIME). And moreover, recently a new PLC standard IEEE 1901.1 is under the progress of standardization which aims at the frequency band of 2-12 MHz. Narrowband PLC is a very important branch of PLC technology due to its low frequency band and low power cost. So far the recent PLC standards, ITU-T G.9903 (G3-PLC) and IEEE 1901.2, are dominating as two of the most robust schemes available. IEEE 1901.2 is a combination of G3-PLC and PRIME while IEEE 1901.2a is an amendment to IEEE 1901.2. Different networking methods exist in different NBPLC standards. There are 2 routing algorithms used in PLC networks for AMI applications: o LOADng (Lightweight On-demand Ad-hoc Distance-vector Routing Protocol Next Generation) is a reactive protocol, operating in layer 2 or layer 3. Hou, et al Expires June 14, 2018 [Page 4] INTERNET DRAFT IPv6 over PLC December 11, 2017 o RPL (Routing Protocol for Low-Power and Lossy Networks) is a proactive protocol operating only in layer 3. LOADng is supported in ITU-T G.9903, and the IEEE 1901.2 standard refers to ITU-T G.9903 for LOAD-based networks. IEEE 1901.2 specifies additionally Information Elements (IEs) which carry metrics from PHY layer to IP layer and the IE content is user-defined. These IEs enable RPL to be used as the routing algorithm in 1901.2 networks. IEEE Standard for Smart Grid Powerline Communication Working Group (SGPLC WG) is currently working on a new PLC standard, IEEE 1901.1, which focuses on the frequency band of 2-12 MHz [IEEE 1901.1]. With balanced bandwidth and communication distance, this promising medium- frequency PLC standard, known as PLC-IoT, is suitable for 6lo applications thus mentioned in this document. Details on this standard is to be determined. 3.1. Protocol Stack The protocol stack for IPv6 over PLC is illustrated in Figure 1 that contains the following elements from bottom to top: PLC PHY Layer, PLC MAC Layer, Adaptation layer for IPv6 over PLC, IPv6 Layer, TCP/UDP Layer and Application Layer. The PLC MAC/PHY layer corresponds to a certain PLC standard such as IEEE 1901.2 or ITU-T G.9903. Details of the 6lo adaptation layer for PLC are illustrated in section 4. Routing protocol like RPL on Network layer is optional according to the specified PLC standard, e.g. IEEE 1901.2. +----------------------------------------+ | Application Layer | +----------------------------------------+ | TCP/UDP | +----------------------------------------+ | | | IPv6 | | | +----------------------------------------+ | Adaptation layer for IPv6 over PLC | +----------------------------------------+ | PLC MAC Layer | | (IEEE 1901.2 / ITU-T G.9903) | +----------------------------------------+ | PLC PHY Layer | | (IEEE 1901.2 / ITU-T G.9903) | +----------------------------------------+ Figure 1: PLC Protocol Stack Hou, et al Expires June 14, 2018 [Page 5] INTERNET DRAFT IPv6 over PLC December 11, 2017 3.2. Addressing Modes Each PLC device has a globally unique 64-bit long address and a 16- bit short address. The long address is set by manufacturers according to 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 Maximum Transmission Unit (MTU) of MAC layer is an important parameter that determines the applicability of fragmentation and reassembly at the adaptation layer of IPv6 over PLC. An IPv6 packet require that every link in the Internet have 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.2 MAC layer supports the MTU of 1576 octets (the original value 1280 byte was updated in 2015 [IEEE 1901.2a]). Though fragmentation and reassembly is not needed in IEEE 1901.2, 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 complete IPv6 packets. For this concern, fragmentation and reassembly as per [RFC4944] MUST be enabled for the G.9903-based scenarios (details can be found in section 4.2.6). 4. Specification of IPv6 over Narrowband PLC Due to the narrow bandwidth and low data rate in NBPLC, a 6lo adaptation layer is needed to support the transmission of IPv6 packets. 6LoWPAN standards [RFC4944], [RFC6775], and [RFC6282] provides useful functionality including link-local IPv6 addresses, stateless address auto-configuration, neighbor discovery and header compression. These standards are referred in the specifications of the 6lo adaptation layer which is illustrated in the following subsections. 4.1. Stateless Address Autoconfiguration PLC devices perform stateless address autoconfiguration according to [RFC4944] so as to obtain an IPv6 Interface Identifier (IID). The 64-bit IID SHALL be derived by insert 16-bit "FFEE" into a "pseudo 48-bit address" which is formed by the 16-bit PAN ID, 16-bit zero and the 16-bit short address as follows: 16_bit_PAN:00FF:FE00:16_bit_short_address Hou, et al Expires June 14, 2018 [Page 6] INTERNET DRAFT IPv6 over PLC December 11, 2017 Considering that this derived IID is not globally unique, the "Universal/Local" (U/L) bit (7th bit) SHALL be set to one and the Individual/Group bit (8th bit) SHALL be set to zero. (The least significant bit of first octet (the I/G bit) indicates either an individual address (I/G=0) or group address (I/G=1), and the second least significant bit (the U/L bit) indicates universal (U/L=0) or local (U/L=1) administration of the address.) 4.2. IPv6 Link Local Address The IPv6 link-local address [RFC4291] for a PLC interface is formed by appending the Interface Identifier, 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 in PLC 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], unless otherwise specified. The Source/Target Link-layer Address option has the following form and the addresses are 16-bit short addresses. Since the 64-bit long address is only used in the joining process, the long address option is not included in this section. 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length=1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | PAN ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 16-bit short Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Padding (all zeros) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 3: Unicast Address Mapping Option fields: Hou, et al Expires June 14, 2018 [Page 7] INTERNET DRAFT IPv6 over PLC December 11, 2017 Type: 1 for Source Link-layer address and 2 for Target Link-layer address. Length: This is the length of this option (including the type and length fields) in units of 8 octets. The value of this field is 1 for the 16-bit PLC short addresses. 4.4. Neighbor Discovery Neighbor Discovery Optimization for 6LoWPANs [RFC6775] describes the neighbor discovery approach in several 6LoWPAN topologies including the mesh topology. In the route-over RPL-based network, the neighbor discovery process in IEEE 1901.2 networks SHALL refer to [RFC6775]. The IEEE 1901.2 PLC devices SHOULD follow Sections 5.3 and 5.4 of [RFC6775] for sending Router Solicitations and processing Router Advertisements. Note that although PLC devices are electrically powered, sleeping mode is still applicable for power saving. In addition, if DHCPv6 is used to assign addresses, Duplicate Address Detection (DAD) is not needed and SHALL NOT be utilized. The mesh-under LOADng-based ITU-T G.9903 network SHOULD NOT proceed the address registration as described in [RFC6775]. ITU-T G.9903 PLC networks SHALL use the 6LoWPAN Context Option (6CO) specified in [RFC6775] (see clause 9.4.1.1 in [ITU-T G.9903]), which can be attached in Router Advertisements (RAs) to disseminate Context IDs (CIDs) to use for compressing prefixes. An implementation for mesh- under operation SHALL use [RFC6775] mechanisms for managing IPv6 prefixes and corresponding header compression context information [RFC6282]. 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 Hou, et al Expires June 14, 2018 [Page 8] INTERNET DRAFT IPv6 over PLC December 11, 2017 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. To minimize redundant fragmentation and reassembly (FAR) in the 6lo adaptation layer, similar functions defined in [RFC4944] MUST only be used when necessary. This document gives a requirement of the use of 6LoWPAN FAR in PLC networks as below: * In PLC networks, if MAC sublayer segmentation and reassembly is supported while the MAC layer supports MTU size of 1280 octets or greater, then 6LoWPAN fragmentation and reassembly as defined in [RFC4944] is not needed and MUST NOT be used. In IEEE 1901.2, since the MAC layer supports a payload of 1280 octets, which is the minimum MTU required by IPv6 packets, there is no need of fragmentation for the IPv6 packet transmission, thus the fragmentation and reassembly defined in [RFC4944] MUST 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]. 4.7. Extension at 6lo Adaptation Layer Apart from the 6lo headers specified in [RFC4944], an additional Command Frame Header is defined for the mesh routing procedure in LOADng protocol. Figure 4 illustrates the format of the Command Frame Header [RFC8066]: The ESC dispatch type (01000000b) indicates an ESC extension type follows (see [RFC4944] and [RFC6282]). Then this 1-octet dispatch field is used as the Command Frame Header and filled with the Command ID. The Command ID can be classified into 4 types: - LOADng message (0x01) - LoWPAN bootstrapping protocol message (0x02) - Reserved by ITU-T (0x03-0x0F) - CMSR protocol messages (0X10-0X1F) The LOADng message is used to provide the default routing protocol LOADng while the LoWPAN bootstrapping protocol message is for the Hou, et al Expires June 14, 2018 [Page 9] INTERNET DRAFT IPv6 over PLC December 11, 2017 LoWPAN bootstrap procedure. The CMSR protocol messages are specified for the Centralized metric-based source routing [ITU-T G.9905] which is out of the scope of this draft. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ESC | Command ID | Command Payload +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 4: Command Frame Header Format of ITU-T G.9903 Command Frame Header appears in the last position if more than one header is present in the 6LoWPAN frame [ITU-T G.9903]. On the other hand, this Command Frame Header MUST appear before the LoWPAN_IPHC dispatch type as per [RFC8066]. * Regarding the order of the command frame header, the inconsistency between G.9903 and RFC8066 still exists and is being solved in ITU-T SG15/Q15. Following these two requirements of header order mentioned above, an example of the header order is illustrated in Figure 5 including the Fragmentation type, Fragmentation header, ESC dispatch type, ESC Extension Type (Command ID), ESC Dispatch Payload (Command Payload), LOWPAN_IPHC Dispatch Type, LOWPAN_IPHC header, and Payload. +-----+-----+-----+-----+-------+-------+---------------+------+ |F typ|F hdr| ESC | EET | EDP |Disptch|LOWPAN_IPHC hdr| Payld| +-----+-----+-----+-----+-------+-------+---------------+------+ Figure 5: A 6LoWPAN packet including the Command Frame Header 5. Internet Connectivity Scenarios and Topologies The network model can be simplified to two kinds of network devices: PAN Coordinator (PCO) and PAN Device. PCO is the coordinator of the PLC subnet and can be seen as a master node while PAN Devices are typically PLC meters and sensors. The IPv6 over PLC networks are built as tree, mesh or star according to the specified using scenarios. Every network requires at least one PCO to communicate with each PAN Device. Note that the PLC topologies included in this section are based on the logical connectivity, not physical links. One common topology in the current PLC scenarios is star. In this case, the communication at the link layer only takes place between a PAN Device and a PCO. The PCO collects data (e.g. smart meter reading) from different nodes, and then concentrates and uploads the Hou, et al Expires June 14, 2018 [Page 10] INTERNET DRAFT IPv6 over PLC December 11, 2017 data through Ethernet or LPWAN (see Figure 6). 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. Such topology has been widely applied in the deployment of smart meters, especially in apartment buildings. PAN Device PAN Device \ / +--------- \ / / \ / + \ / | PAN Device ------ PCO ========== | Internet / \ | / \ + / \ \ / \ +--------- PAN Device PAN Device <----------------------> PLC subnet (IPv6 over PLC packet) Figure 6: PLC Star Network connected to the Internet Tree topology is used when the distance between a device A and PCO is beyond the PLC allowed limit while 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 Proxy Coordinator. For this scenario, the link layer communications take place between device A and device B, and between device B and PCO. An example of PLC tree network is depicted in Figure 7. This topology can be applied in the 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, 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 as depicted in [RFC8036]. Tree topology is suitable for the AMI scenarios that require large coverage but low density, e.g. the deployment of smart meters in rural areas. Hou, et al Expires June 14, 2018 [Page 11] INTERNET DRAFT IPv6 over PLC December 11, 2017 PAN Device \ +--------- PAN Device \ / \ \ + \ \ | PAN Device -- PCO ========== | Internet / / | / / + PAN Device---PAN Device / \ / +--------- PAN Device---PAN Device <-------------------------> PLC subnet (IPv6 over PLC packet) Figure 7: 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 8), 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). LOADng enables direct pan device to pan devices (without being obliged to get through the pan coordinator) which significantly improves performances in typical use cases like charging station to electric vehicle (EV) communications. PAN Device---PAN Device / \ / \ +--------- / \ / \ / / \ / \ + / \ / \ | PAN Device--PAN Device---PCO ========== | Internet \ / \ / | \ / \ / + \ / \ / \ \ / \ / +--------- PAN Device---PAN Device <-------------------------------> PLC subnet (IPv6 over PLC packet) Figure 8: PLC Mesh Network connected to the Internet Hou, et al Expires June 14, 2018 [Page 12] INTERNET DRAFT IPv6 over PLC December 11, 2017 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. 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], and [RFC7217] provide valuable information for IID formation with high security, and are RECOMMENDED for privacy- required IPv6-enabled PLC network deployments. 8. Acknowledgements We are grateful to the members of the IETF 6LoWPAN 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.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, December 1998, . [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, September 2007, . [RFC6282] Hui, J. and P. Thubert, "Compression Format for IPv6 Datagrams over IEEE 802.15.4-Based Networks", RFC 6282, September 2011, . [RFC6775] Shelby, Z., Chakrabarti, S., Nordmark, E., and C. Bormann, "Neighbor Discovery Optimization for IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs)", RFC 6775, November 2012, . 9.2. Informative References [draft-ietf-6lo-ap-nd-02] Sarikaya, B., Thubert, P. and M. Sethi, "Address Protected Neighbor Discovery for Low-power and Lossy Networks", draft-ietf-6lo-ap-nd-02, May 2017, . [draft-popa-6lo-6loplc] Popa, D. and J.H. Hui, "6LoPLC: Transmission of IPv6 Packets over IEEE 1901.2 Narrowband Powerline Communication Networks", draft-popa-6lo-6loplc-ipv6-over- ieee19012-networks-00, March 2014, . [draft-rashid-6lo-iid-assignment-03] Sangi, AR., Chen, M. and C. Perkins, "Designating 6LBR for IID Assignment", draft- rashid-6lo-iid-assignment-03, March 2017, . [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, work in progress, . [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, . [ITU-T G.9960] International Telecommunication Union, "Unified high- speed wireline-based home networking transceivers - System architecture and physical layer specification", ITU-T G.9960, December 2011, . [ITU-T G.9961] International Telecommunication Union, "Unified high- speed wireline-based home networking transceivers - Data link layer specification", ITU-T G.9961, June 2010, . [RFC8036] Cam-Winget, N., 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, January 2017, . [RFC8065] D. Thaler, " Privacy Considerations for IPv6 Adaptation- Layer Mechanisms", RFC 8065, Februray 2017, . [RFC8066] Chakrabarti, S., Montenegro, G., Droms, R. and J. Woodyatt, "IPv6 over Low-Power Wireless Personal Area Network (6LoWPAN) ESC Dispatch Code Points and Guidelines", RFC 8066, Februray 2017, . Authors' Addresses Jianqiang Hou Huawei Technologies 101 Software Avenue, Nanjing 210012 China Hou, et al Expires June 14, 2018 [Page 15] INTERNET DRAFT IPv6 over PLC December 11, 2017 Phone: +86 15852944235 Email: houjianqiang@huawei.com Yong-Geun Hong Electronics and Telecommunications Research Institute 161 Gajeong-Dong Yuseung-Gu Daejeon 305-700 Korea Phone: +82 42 860 6557 Email: yghong@etri.re.kr Xiaojun Tang State Grid Electric Power Research Institute 19 Chengxin Avenue Nanjing 211106 China Phone: +86-25-81098508 Email: itc@sgepri.sgcc.com.cn Hou, et al Expires June 14, 2018 [Page 16]