idnits 2.17.00 (12 Aug 2021) /tmp/idnits64455/draft-ietf-6lo-plc-08.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (January 10, 2022) is 131 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: draft-ietf-6tisch-minimal-security has been published as RFC 9031 == Outdated reference: draft-ietf-emu-eap-noob has been published as RFC 9140 == Outdated reference: A later version (-13) exists of draft-ietf-roll-aodv-rpl-11 Summary: 0 errors (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 6Lo Working Group J. Hou 3 Internet-Draft B. Liu 4 Intended status: Standards Track Huawei Technologies 5 Expires: July 14, 2022 Y-G. Hong 6 Daejeon University 7 X. Tang 8 SGEPRI 9 C. Perkins 10 Lupin Lodge 11 January 10, 2022 13 Transmission of IPv6 Packets over PLC Networks 14 draft-ietf-6lo-plc-08 16 Abstract 18 Power Line Communication (PLC), namely using the electric-power lines 19 for indoor and outdoor communications, has been widely applied to 20 support Advanced Metering Infrastructure (AMI), especially smart 21 meters for electricity. The existing electricity infrastructure 22 facilitates the expansion of PLC deployments due to its potential 23 advantages in terms of cost and convenience. Moreover, a wide 24 variety of accessible devices raises the potential demand of IPv6 for 25 future applications. This document describes how IPv6 packets are 26 transported over constrained PLC networks, such as ITU-T G.9903, IEEE 27 1901.1 and IEEE 1901.2. 29 Status of This Memo 31 This Internet-Draft is submitted in full conformance with the 32 provisions of BCP 78 and BCP 79. 34 Internet-Drafts are working documents of the Internet Engineering 35 Task Force (IETF). Note that other groups may also distribute 36 working documents as Internet-Drafts. The list of current Internet- 37 Drafts is at https://datatracker.ietf.org/drafts/current/. 39 Internet-Drafts are draft documents valid for a maximum of six months 40 and may be updated, replaced, or obsoleted by other documents at any 41 time. It is inappropriate to use Internet-Drafts as reference 42 material or to cite them other than as "work in progress." 44 This Internet-Draft will expire on July 14, 2022. 46 Copyright Notice 48 Copyright (c) 2022 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (https://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with respect 56 to this document. Code Components extracted from this document must 57 include Simplified BSD License text as described in Section 4.e of 58 the Trust Legal Provisions and are provided without warranty as 59 described in the Simplified BSD License. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 64 2. Requirements Notation and Terminology . . . . . . . . . . . . 3 65 3. Overview of PLC . . . . . . . . . . . . . . . . . . . . . . . 5 66 3.1. Protocol Stack . . . . . . . . . . . . . . . . . . . . . 5 67 3.2. Addressing Modes . . . . . . . . . . . . . . . . . . . . 6 68 3.3. Maximum Transmission Unit . . . . . . . . . . . . . . . . 6 69 3.4. Routing Protocol . . . . . . . . . . . . . . . . . . . . 7 70 4. IPv6 over PLC . . . . . . . . . . . . . . . . . . . . . . . . 7 71 4.1. Stateless Address Autoconfiguration . . . . . . . . . . . 8 72 4.2. IPv6 Link Local Address . . . . . . . . . . . . . . . . . 9 73 4.3. Unicast Address Mapping . . . . . . . . . . . . . . . . . 9 74 4.3.1. Unicast Address Mapping for IEEE 1901.1 . . . . . . . 9 75 4.3.2. Unicast Address Mapping for IEEE 1901.2 and ITU-T 76 G.9903 . . . . . . . . . . . . . . . . . . . . . . . 10 77 4.4. Neighbor Discovery . . . . . . . . . . . . . . . . . . . 11 78 4.5. Header Compression . . . . . . . . . . . . . . . . . . . 12 79 4.6. Fragmentation and Reassembly . . . . . . . . . . . . . . 13 80 5. Internet Connectivity Scenarios and Topologies . . . . . . . 14 81 6. Operations and Manageability Considerations . . . . . . . . . 16 82 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 83 8. Security Considerations . . . . . . . . . . . . . . . . . . . 16 84 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 18 85 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 18 86 10.1. Normative References . . . . . . . . . . . . . . . . . . 18 87 10.2. Informative References . . . . . . . . . . . . . . . . . 20 88 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22 90 1. Introduction 92 The idea of using power lines for both electricity supply and 93 communication can be traced back to the beginning of the last 94 century. Using the existing power grid to transmit messages, Power 95 Line Communication (PLC) is a good candidate for supporting various 96 service scenarios such as in houses and offices, in trains and 97 vehicles, in smart grid and advanced metering infrastructure (AMI) 98 [SCENA]. The data acquisition devices in these scenarios share 99 common features such as fixed position, large quantity, low data rate 100 and low power consumption. 102 Although PLC technology has evolved over several decades, it has not 103 been fully adapted for IPv6-based constrained networks. The 104 resource-constrained IoT-related scenarios lie in the low voltage PLC 105 networks with most applications in the area of Advanced Metering 106 Infrastructure (AMI), Vehicle-to-Grid communications, in-home energy 107 management, and smart street lighting. IPv6 is important for PLC 108 networks, due to its large address space and efficient address auto- 109 configuration. 111 This document provides a brief overview of PLC technologies. Some of 112 them have LLN (low power and lossy network) characteristics, i.e., 113 limited power consumption, memory and processing resources. This 114 document specifies the transmission of IPv6 packets over those 115 "constrained" PLC networks. The general approach is to adapt 116 elements of the 6LoWPAN (IPv6 over Low-Power Wireless Personal Area 117 Network) and 6lo (IPv6 over Networks of Resource-constrained Nodes) 118 specifications, such as [RFC4944], [RFC6282], [RFC6775] and [RFC8505] 119 to constrained PLC networks. 121 2. Requirements Notation and Terminology 123 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 124 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 125 "OPTIONAL" in this document are to be interpreted as described in 126 BCP14 [RFC2119] [RFC8174] when, and only when, they appear in all 127 capitals, as shown here. 129 This document uses the following acronyms and terminologies: 131 6BBR: 6LoWPAN Backbone Router 133 6LBR: 6LoWPAN Border Router 135 6LoWPAN: IPv6 over Low-Power Wireless Personal Area Network 137 6lo: IPv6 over Networks of Resource-constrained Nodes 138 6LR: 6LoWPAN Router 140 AMI: Advanced Metering Infrastructure 142 BBPLC: Broadband Power Line Communication 144 Coordinator: A device capable of relaying messages 146 DAD: Duplicate Address Detection 148 IID: IPv6 Interface Identifier 150 LLN: Low power and Lossy Network 152 MTU: Maximum Transmission Unit 154 NBPLC: Narrowband Power Line Communication 156 PAN: Personal Area Network 158 PANC: PAN Coordinator, a coordinator which also acts as the primary 159 controller of a PAN 161 PLC: Power Line Communication 163 PLC device: An entity that follows the PLC standards and implements 164 the protocol stack described in this draft 166 RPL: IPv6 Routing Protocol for Low-Power and Lossy Networks 168 RA: Router Advertisement 170 Below is a mapping table of the terminology between [IEEE_1901.2], 171 [IEEE_1901.1], [ITU-T_G.9903] and this document. 173 +---------------+----------------+------------------+---------------+ 174 | IEEE 1901.2 | IEEE 1901.1 | ITU-T G.9903 | This document | 175 +---------------+----------------+------------------+---------------+ 176 | PAN | Central | PAN Coordinator | PAN | 177 | Coordinator | Coordinator | | Coordinator | 178 | | | | | 179 | Coordinator | Proxy | Full-function | Coordinator | 180 | | Coordinator | device | | 181 | | | | | 182 | Device | Station | PAN Device | PLC Device | 183 +---------------+----------------+------------------+---------------+ 185 Table 1: Terminology Mapping between PLC standards 187 3. Overview of PLC 189 PLC technology enables convenient two-way communications for home 190 users and utility companies to monitor and control electric plugged 191 devices such as electricity meters and street lights. PLC can also 192 be used in smart home scenarios, such as the control of indoor lights 193 and switches. Due to the large range of communication frequencies, 194 PLC is generally classified into two categories: Narrowband PLC 195 (NBPLC) for automation of sensors (which have a low frequency band 196 and low power cost), and Broadband PLC (BBPLC) for home and industry 197 networking applications. 199 Various standards have been addressed on the MAC and PHY layers for 200 this communication technology, e.g., BBPLC (1.8-250 MHz) including 201 IEEE 1901 and ITU-T G.hn, and NBPLC (3-500 kHz) including ITU-T 202 G.9902 (G.hnem), ITU-T G.9903 (G3-PLC) [ITU-T_G.9903], ITU-T G.9904 203 (PRIME), IEEE 1901.2 [IEEE_1901.2] (a combination of G3-PLC and PRIME 204 PLC) and IEEE 1901.2a [IEEE_1901.2a] (an amendment to IEEE 1901.2). 206 A new PLC standard IEEE 1901.1 [IEEE_1901.1], which is aimed at the 207 medium frequency band of less than 12 MHz, has been published by the 208 IEEE standard for Smart Grid Powerline Communication Working Group 209 (SGPLC WG). IEEE 1901.1 balances the needs for bandwidth versus 210 communication range, and is thus a promising option for 6lo 211 applications. 213 This specification is focused on IEEE 1901.1, IEEE 1901.2, and ITU-T 214 G.9903. 216 3.1. Protocol Stack 218 The protocol stack for IPv6 over PLC is illustrated in Figure 1. The 219 PLC MAC/PHY layer corresponds to IEEE 1901.1, IEEE 1901.2 or ITU-T 220 G.9903. The 6lo adaptation layer for PLC is illustrated in 221 Section 4. For multihop tree and mesh topologies, a routing protocol 222 is likely to be necessary. The routes can be built in mesh-under 223 mode at layer 2 or in route-over mode at layer-3, as explained in 224 Section 3.4. 226 +----------------------------------------+ 227 | Application Layer | 228 +----------------------------------------+ 229 | Transport Layer | 230 +----------------------------------------+ 231 | | 232 | IPv6 | 233 | | 234 +----------------------------------------+ 235 | Adaptation layer for IPv6 over PLC | 236 +----------------------------------------+ 237 | PLC MAC Layer | 238 +----------------------------------------+ 239 | PLC PHY Layer | 240 +----------------------------------------+ 242 Figure 1: PLC Protocol Stack 244 3.2. Addressing Modes 246 Each PLC device has a globally unique long address of 48-bits 247 ([IEEE_1901.1]) or 64-bits ([IEEE_1901.2], [ITU-T_G.9903]) and a 248 short address of 12-bits ([IEEE_1901.1]) or 16-bits ([IEEE_1901.2], 249 [ITU-T_G.9903]). The long address is set by the manufacturer 250 according to the IEEE EUI-48 MAC address or the IEEE EUI-64 address. 251 Each PLC device joins the network by using the long address and 252 communicates with other devices by using the short address after 253 joining the network. Short addresses can be assigned during the 254 onboarding process, by the PANC or the JRC (join registrar/ 255 coordinator) in CoJP (Constrained Join Protocol) 256 [I-D.ietf-6tisch-minimal-security]. 258 3.3. Maximum Transmission Unit 260 The Maximum Transmission Unit (MTU) of the MAC layer determines 261 whether fragmentation and reassembly are needed at the adaptation 262 layer of IPv6 over PLC. IPv6 requires an MTU of 1280 octets or 263 greater; thus for a MAC layer with MTU lower than this limit, 264 fragmentation and reassembly at the adaptation layer are required. 266 The IEEE 1901.1 MAC supports upper layer packets up to 2031 octets. 267 The IEEE 1901.2 MAC layer supports an MTU of 1576 octets (the 268 original value of 1280 bytes was updated in 2015 [IEEE_1901.2a]). 269 Though these two technologies can support IPv6 originally without 270 fragmentation and reassembly, it is possible to configure a smaller 271 MTU in high-noise communication environment. Thus the 6lo functions, 272 including header compression, fragmentation and reassembly, are still 273 applicable and useful. 275 The MTU for ITU-T G.9903 is 400 octets, insufficient for supporting 276 IPv6's MTU. For this reason, fragmentation and reassembly is 277 required for G.9903-based networks to carry IPv6. 279 3.4. Routing Protocol 281 Routing protocols suitable for use in PLC networks include: 283 o RPL (Routing Protocol for Low-Power and Lossy Networks) [RFC6550] 284 is a layer-3 routing protocol. AODV-RPL [I-D.ietf-roll-aodv-rpl] 285 updates RPL to include reactive, point-to-point, and asymmetric 286 routing. IEEE 1901.2 specifies Information Elements (IEs) with 287 MAC layer metrics, which can be provided to L3 routing protocol 288 for parent selection. 290 o IEEE 1901.1 supports L2 routing. Each PLC node maintains an L2 291 routing table, in which each route entry comprises the short 292 addresses of the destination and the related next hop. The route 293 entries are built during the network establishment via a pair of 294 association request/confirmation messages. The route entries can 295 be changed via a pair of proxy change request/confirmation 296 messages. These association and proxy change messages must be 297 approved by the central coordinator (PANC in this document). 299 o LOADng is a reactive protocol operating at layer-2 or layer-3. 300 Currently, LOADng is supported in ITU-T G.9903 [ITU-T_G.9903], and 301 the IEEE 1901.2 standard refers to ITU-T G.9903 for LOAD-based 302 networks. 304 4. IPv6 over PLC 306 A PLC node distinguishes between an IPv6 PDU and a non-IPv6 PDU based 307 on the equivalent of a EtherType in a layer-2 PLC PDU. [RFC7973] 308 defines a Ethertype of "A0ED" for LoWPAN encapsulation, and this 309 information can be carried in the IE field in the MAC header of 310 [IEEE_1901.2] or [ITU-T_G.9903]. And regarding [IEEE_1901.1], the IP 311 packet type has been defined with the corresponding MAC Service Data 312 Unit (MSDU) type value 49. And the 4-bit Internet Protocol version 313 number in the IP header helps to distinguish between an IPv4 PDU and 314 an IPv6 PDU. 316 6LoWPAN and 6lo standards [RFC4944], [RFC6282], [RFC6775], and 317 [RFC8505] provide useful functionality including link-local IPv6 318 addresses, stateless address auto-configuration, neighbor discovery, 319 header compression, fragmentation, and reassembly. However, due to 320 the different characteristics of the PLC media, the 6LoWPAN 321 adaptation layer, as it is, cannot perfectly fulfill the requirements 322 of PLC environments. These considerations suggest the need for a 323 dedicated adaptation layer for PLC, which is detailed in the 324 following subsections. 326 4.1. Stateless Address Autoconfiguration 328 To obtain an IPv6 Interface Identifier (IID), a PLC device performs 329 stateless address autoconfiguration [RFC4944]. The autoconfiguration 330 can be based on either a long or short link-layer address. 332 The IID can be based on the device's 48-bit MAC address or its EUI-64 333 identifier [EUI-64]. A 48-bit MAC address MUST first be extended to 334 a 64-bit Interface ID by inserting 0xFFFE at the fourth and fifth 335 octets as specified in [RFC2464]. The IPv6 IID is derived from the 336 64-bit Interface ID by inverting the U/L bit [RFC4291]. 338 For IEEE 1901.2 and ITU-T G.9903, a 48-bit "pseudo-address" is formed 339 by the 16-bit PAN ID, 16 zero bits and the 16-bit short address. 340 Then, the 64-bit Interface ID MUST be derived by inserting 16-bit 341 0xFFFE into as follows: 343 16_bit_PAN:00FF:FE00:16_bit_short_address 345 For the 12-bit short addresses used by IEEE 1901.1, the 48-bit 346 pseudo-address is formed by 24-bit NID (Network IDentifier, YYYYYY), 347 12 zero bits and a 12-bit TEI (Terminal Equipment Identifier, XXX). 348 The 64-bit Interface ID MUST be derived by inserting 16-bit 0xFFFE 349 into this 48-bit pseudo-address as follows: 351 YYYY:YYFF:FE00:0XXX 353 As investigated in [RFC7136], besides [RFC4291], some other IID 354 generation methods defined in IETF do not imply any semantics for the 355 "Universal/Local" (U/L) bit (7th bit) and the Individual/Group bit 356 (8th bit), so that these two bits are not reliable indicators for 357 their original meanings. Thus when using an IID derived by a short 358 address, the operators of the PLC network can choose to comply with 359 original meaning of these two bits or not. If so, since the IID 360 derived from the short address is not global, these two bits MUST 361 both be set to zero. In order to avoid any ambiguity in the derived 362 Interface ID, these two bits MUST NOT be used to generate the PANID 363 (for IEEE 1901.2 and ITU-T G.9903) or NID (for IEEE 1901.1). In 364 other words, the PANID or NID MUST always be chosen so that these 365 bits are zeros. If not, the operator must be aware that these two 366 bits are not reliable indicators, and the IID cannot be transformed 367 back into a short link layer address via a reverse operation of the 368 mechanism prsented above. 370 For privacy reasons, the IID derived from the MAC address (with 371 padding and bits flipping) SHOULD only be used for link-local address 372 configuration. A PLC host SHOULD use the IID derived from the link- 373 layer short address to configure IPv6 addresses used for 374 communication with the public network; otherwise, the host's MAC 375 address is exposed. As per [RFC8065], when short addresses are used 376 on PLC links, a shared secret key or version number from the 377 Authoritative Border Router Option [RFC6775] can be used to improve 378 the entropy of the hash input, thus the generated IID can be spread 379 out to the full range of the IID address space while stateless 380 address compression is still allowed. The hash algorithm by default 381 of the implementations SHOULD be SHA256, using the version number, 382 the PANID/NID and the short address as the input arguments, and the 383 256-bits hash output is truncated into the IID by taking the high 64 384 bits. 386 4.2. IPv6 Link Local Address 388 The IPv6 link-local address [RFC4291] for a PLC interface is formed 389 by appending the IID, as defined above, to the prefix FE80::/64 (see 390 Figure 2). 392 10 bits 54 bits 64 bits 393 +----------+-----------------------+----------------------------+ 394 |1111111010| (zeros) | Interface Identifier | 395 +----------+-----------------------+----------------------------+ 397 Figure 2: IPv6 Link Local Address for a PLC interface 399 4.3. Unicast Address Mapping 401 The address resolution procedure for mapping IPv6 unicast addresses 402 into PLC link-layer addresses follows the general description in 403 section 7.2 of [RFC4861]. [RFC6775] improves this procedure by 404 eliminating usage of multicast NS. The resolution is realized by the 405 NCEs (neighbor cache entry) created during the address registration 406 at the routers. [RFC8505] further improves the registration 407 procedure by enabling multiple LLNs to form an IPv6 subnet, and by 408 inserting a link-local address registration to better serve proxy 409 registration of new devices. 411 4.3.1. Unicast Address Mapping for IEEE 1901.1 413 The Source/Target Link-layer Address options for IEEE_1901.1 used in 414 the Neighbor Solicitation and Neighbor Advertisement have the 415 following form. 417 0 1 2 3 418 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 419 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 420 | Type | Length=1 | NID : 421 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 422 :NID (continued)| Padding (all zeros) | TEI | 423 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 425 Figure 3: Unicast Address Mapping for IEEE 1901.1 427 Option fields: 429 Type: 1 for Source Link-layer Address and 2 for Target Link-layer 430 Address. 432 Length: The length of this option (including type and length fields) 433 in units of 8 octets. The value of this field is 1 for the 434 12-bit IEEE 1901.1 PLC short addresses. 436 NID: 24-bit Network IDentifier 438 Padding: 12 zero bits 440 TEI: 12-bit Terminal Equipment Identifier 442 4.3.2. Unicast Address Mapping for IEEE 1901.2 and ITU-T G.9903 444 The Source/Target Link-layer Address options for IEEE_1901.2 and 445 ITU-T G.9903 used in the Neighbor Solicitation and Neighbor 446 Advertisement have the following form. 448 0 1 2 3 449 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 450 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 451 | Type | Length=1 | PAN ID | 452 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 453 | Padding (all zeros) | Short Address | 454 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 456 Figure 4: Unicast Address Mapping for IEEE 1901.2 458 Option fields: 460 Type: 1 for Source Link-layer Address and 2 for Target Link-layer 461 Address. 463 Length: The length of this option (including type and length fields) 464 in units of 8 octets. The value of this field is 1 for the 465 16-bit IEEE 1901.2 PLC short addresses. 467 PAN ID: 16-bit PAN IDentifier 469 Padding: 16 zero bits 471 Short Address: 16-bit short address 473 4.4. Neighbor Discovery 475 Neighbor discovery procedures for 6LoWPAN networks are described in 476 Neighbor Discovery Optimization for 6LoWPANs [RFC6775] and [RFC8505]. 477 These optimizations support the registration of sleeping hosts. 478 Although PLC devices are electrically powered, sleeping mode SHOULD 479 still be used for power saving. 481 For IPv6 address prefix dissemination, Router Solicitations (RS) and 482 Router Advertisements (RA) MAY be used as per [RFC6775]. If the PLC 483 network uses route-over, the IPv6 prefix MAY be disseminated by the 484 layer-3 routing protocol, such as RPL, which may include the prefix 485 in the DIO (DODAG Information Object) message. As per [RFC9010], it 486 is possible to have PLC devices configured as RPL-unaware-leaves, 487 which do not participate in RPL at all, along with RPL-aware PLC 488 devices. In this case, the prefix dissemination SHOULD use the RS/RA 489 messages. 491 For context information dissemination, Router Advertisements (RA) 492 MUST be used as per [RFC6775]. The 6LoWPAN context option (6CO) MUST 493 be included in the RA to disseminate the Context IDs used for prefix 494 and/or address compression. 496 For address registration in route-over mode, a PLC device MUST 497 register its addresses by sending a unicast link-local Neighbor 498 Solicitation to the 6LR. If the registered address is link-local, 499 the 6LR SHOULD NOT further register it to the registrar (6LBR, 6BBR). 500 Otherwise, the address MUST be registered via an ARO or EARO included 501 in the DAR ([RFC6775]) or EDAR ([RFC8505]) messages. For RFC8505 502 compliant PLC devices, the 'R' flag in the EARO MUST be set when 503 sending Neighbor Solicitations in order to extract the status 504 information in the replied Neighbor Advertisements from the 6LR. If 505 DHCPv6 is used to assign addresses or the IPv6 address is derived 506 from unique long or short link layer address, Duplicate Address 507 Detection (DAD) SHOULD NOT be utilized. Otherwise, the DAD MUST be 508 performed at the 6LBR (as per [RFC6775]) or proxied by the routing 509 registrar (as per [RFC8505]). The registration status is fed back 510 via the DAC or EDAC message from the 6LBR and the Neighbor 511 Advertisement (NA) from the 6LR. The section 6 of [RFC8505] how 512 RFC6775-only devices work with RFC8505-updated devices. 514 For address registration in mesh-under mode, since all the PLC 515 devices are link-local neighbors to the 6LBR, DAR/DAC or EDAR/EDAC 516 messages are not required. A PLC device MUST register its addresses 517 by sending a unicast NS message with an ARO or EARO. The 518 registration status is fed back via the NA message from the 6LBR. 520 4.5. Header Compression 522 The compression of IPv6 datagrams within PLC MAC frames refers to 523 [RFC6282], which updates [RFC4944]. Header compression as defined in 524 [RFC6282] which specifies the compression format for IPv6 datagrams 525 on top of IEEE 802.15.4, is the basis for IPv6 header compression in 526 PLC. For situations when PLC MAC MTU cannot support the 1280-octet 527 IPv6 packet, headers MUST be compressed according to [RFC6282] 528 encoding formats, including the Dispatch Header, the LOWPAN_IPHC and 529 the compression residu carried in-line. 531 For IEEE 1901.2 and G.9903, the IP header compression follows the 532 instruction in [RFC6282]. However, additional adaptation MUST be 533 considered for IEEE 1901.1 since it has a short address of 12 bits 534 instead of 16 bits. The only modification is the semantics of the 535 "Source Address Mode" and the "Dstination Address Mode" when set as 536 "10" in the section 3.1 of [RFC6282], which is illustrated as 537 following. 539 SAM: Source Address Mode: 541 If SAC=0: Stateless compression 543 10: 16 bits. The first 112 bits of the address are elided. The 544 value of the first 64 bits is the link-local prefix padded with 545 zeros. The following 64 bits are 0000:00ff:fe00:0XXX, where 546 0XXX are the 16 bits carried in-line. 548 If SAC=1: stateful context-based compression 550 10: 16 bits. The address is derived using context information and 551 the 16 bits carried in-line. Bits covered by context 552 information are always used. Any IID bits not covered by 553 context information are taken directly from their corresponding 554 bits in the 16-bit to IID mapping given by 0000:00ff:fe00:0XXX, 555 where 0XXX are the 16 bits carried inline. Any remaining bits 556 are zero. 558 DAM: Destination Address Mode: 560 If M=0 and DAC=0: Stateless compression 562 10: 16 bits. The first 112 bits of the address are elided. The 563 value of the first 64 bits is the link-local prefix padded with 564 zeros. The following 64 bits are 0000:00ff: fe00:0XXX, where 565 0XXX are the 16 bits carried in-line. 567 If M=0 and DAC=1: stateful context-based compression 569 10: 16 bits. The address is derived using context information and 570 the 16 bits carried in-line. Bits covered by context 571 information are always used. Any IID bits not covered by 572 context information are taken directly from their corresponding 573 bits in the 16-bit to IID mapping given by 0000:00ff:fe00:0XXX, 574 where XXXX are the 16 bits carried in- line. Any remaining 575 bits are zero. 577 4.6. Fragmentation and Reassembly 579 The constrained PLC MAC layer provides the function of fragmentation 580 and reassembly. However, fragmentation and reassembly is still 581 required at the adaptation layer, if the MAC layer cannot support the 582 minimum MTU demanded by IPv6, which is 1280 octets. 584 In IEEE 1901.1 and IEEE 1901.2, the MAC layer supports payloads as 585 big as 2031 octets and 1576 octets respectively. However, when the 586 channel condition is noisy, smaller packets have higher transmission 587 success rate, the operator can choose to configure smaller MTU at the 588 MAC layer. If the configured MTU is smaller than 1280 octets, the 589 fragmentation and reassembly defined in [RFC4944] MUST be used. 591 In ITU-T G.9903, the maximum MAC payload size is fixed to 400 octets, 592 so to cope with the required MTU of 1280 octets by IPv6, 593 fragmentation and reassembly at the 6lo adaptation layer MUST be 594 provided as specified in [RFC4944]. 596 [RFC4944] uses a 16-bit datagram tag to identify the fragments of the 597 same IP packet. [RFC4963] specifies that at high data rates, the 598 16-bit IP identification field is not large enough to prevent 599 frequent incorrectly assembled IP fragments. For constrained PLC, 600 the data rate is much lower than the situation mentioned in RFC4963, 601 thus the 16-bit tag is sufficient to assemble the fragments 602 correctly. 604 5. Internet Connectivity Scenarios and Topologies 606 The PLC network model can be simplified to two kinds of network 607 device: PAN Coordinator (PANC) and PLC Device. The PANC is the 608 primary coordinator of the PLC subnet and can be seen as a primary 609 node; PAN Devices are typically PLC meters and sensors. The address 610 registration and DAD features can also be deployed on the PANC, for 611 example the 6LBR [RFC6775] or the routing registrar in [RFC8505]. 612 IPv6 over PLC networks are built as trees, meshes or stars topology 613 according to the use cases. Generally, each PLC network has one 614 PANC. In some cases, the PLC network can have alternate coordinators 615 to replace the PANC when the PANC leaves the network for some reason. 616 Note that the PLC topologies in this section are based on logical 617 connectivity, not physical links. The term "PLC subnet" refers to a 618 multilink subnet, in which the PLC devices share the same address 619 prefix. 621 The star topology is common in current PLC scenarios. In single-hop 622 star topologies, communication at the link layer only takes place 623 between a PAN Device and a PANC. The PANC typically collects data 624 (e.g., a meter reading) from the PAN devices, and then concentrates 625 and uploads the data through Ethernet or Cellular networks (see 626 Figure 5). The collected data is transmitted by the smart meters 627 through PLC, aggregated by a concentrator, sent to the utility and 628 then to a Meter Data Management System for data storage, analysis and 629 billing. This topology has been widely applied in the deployment of 630 smart meters, especially in apartment buildings. 632 PLC Device PLC Device 633 \ / +--------- 634 \ / / 635 \ / + 636 \ / | 637 PLC Device ------ PANC ===========+ Internet 638 / \ | 639 / \ + 640 / \ \ 641 / \ +--------- 642 PLC Device PLC Device 644 <----------------------> 645 PLC subnet (IPv6 over PLC) 647 Figure 5: PLC Star Network connected to the Internet 649 A tree topology is useful when the distance between a device A and 650 the PANC is beyond the PLC allowed limit and there is another device 651 B in between able to communicate with both sides. Device B in this 652 case acts both as a PLC Device and a Coordinator. For this scenario, 653 the link layer communications take place between device A and device 654 B, and between device B and PANC. An example of a PLC tree network 655 is depicted in Figure 6. This topology can be applied in smart 656 street lighting, where the lights adjust the brightness to reduce 657 energy consumption while sensors are deployed on the street-lights to 658 provide information such as light intensity, temperature, and 659 humidity. The data transmission distance in the street lighting 660 scenario is normally above several kilometers, thus a PLC tree 661 network is required. A more sophisticated AMI network may also be 662 constructed into the tree topology which is depicted in [RFC8036]. A 663 tree topology is suitable for AMI scenarios that require large 664 coverage but low density, e.g., the deployment of smart meters in 665 rural areas. RPL is suitable for maintenance of a tree topology in 666 which there is no need for communication directly between PAN 667 devices. 669 PLC Device 670 \ +--------- 671 PLC Device \ / 672 \ \ + 673 \ \ | 674 Coordinator -- PANC ===========+ Internet 675 / / | 676 / / + 677 PLC Device---PLC Device / \ 678 / +--------- 679 PLC Device---PLC Device 681 <-------------------------> 682 PLC subnet (IPv6 over PLC) 684 Figure 6: PLC Tree Network connected to the Internet 686 Mesh networking in PLC is of great potential applications and has 687 been studied for several years. By connecting all nodes with their 688 neighbors in communication range (see Figure 7), a mesh topology 689 dramatically enhances the communication efficiency and thus expands 690 the size of PLC networks. A simple use case is the smart home 691 scenario where the ON/OFF state of air conditioning is controlled by 692 the state of home lights (ON/OFF) and doors (OPEN/CLOSE). AODV-RPL 693 ([I-D.ietf-roll-aodv-rpl]) enables direct PLC device to PLC device 694 communication, without being obliged to transmit frames through the 695 PANC, which is a requirement often cited for AMI infrastructure. 697 PLC Device---PLC Device 698 / \ / \ +--------- 699 / \ / \ / 700 / \ / \ + 701 / \ / \ | 702 PLC Device--PLC Device---PANC ===========+ Internet 703 \ / \ / | 704 \ / \ / + 705 \ / \ / \ 706 \ / \ / +--------- 707 PLC Device---PLC Device 709 <-------------------------------> 710 PLC subnet (IPv6 over PLC) 712 Figure 7: PLC Mesh Network connected to the Internet 714 6. Operations and Manageability Considerations 716 The constrained PLC networks are not managed in the same way as an 717 enterprise network or a carrier network. Constrained PLC networks, 718 like the other IoT networks, are designed to be self-organized and 719 self-managed. The software or firmware is flashed into the devices 720 before deployment by the vendor or operator. And during the 721 deployment process, the devices are bootstrapped, and no extra 722 configuration is needed to get the devices connected to each other. 723 Once a device becomes offline, it goes back to the bootstrapping 724 stage and tries to rejoin the network. The onboarding status of the 725 devices and the topology of the PLC network can be visualized via the 726 PANC. The recently-formed iotops WG in IETF is aiming to identify 727 the requirements in IoT network management, and operational practices 728 will be published. Developers and operators of PLC networks should 729 be able to learn operational experiences from this WG. 731 7. IANA Considerations 733 There are no IANA considerations related to this document. 735 8. Security Considerations 737 Due to the high accessibility of power grids, PLC might be 738 susceptible to eavesdropping within its communication coverage, e.g., 739 one apartment tenant may have the chance to monitor the other smart 740 meters in the same apartment building. Link layer security 741 mechanisms, such as payload encryption and devcie authentication, are 742 designed in the PLC technologies mentioned in this document. 744 Malicious PLC devices could paralyze the whole network via DOS 745 attacks, e.g., keep joining and leaving the network frequently, or 746 sending multicast routing messages containing fake metrics. A device 747 may also inadvertently join a wrong or even malicious network, 748 exposing its data to malicious users. When communicating with a 749 device outside the PLC network, the traffic has to go through the 750 PANC. Thus the PANC must be a trusted entity. Moreover, the PLC 751 network must prevent malicious devices to join in the network. Thus 752 Mutual authentication of a PLC network and a new device is important, 753 and it can be conducted during the onboarding process of the new 754 device. Methods include protocols such as [RFC7925] (exchanging pre- 755 installed certificates over DTLS), [I-D.ietf-6tisch-minimal-security] 756 (which uses pre-shared keys), and 757 [I-D.ietf-6tisch-dtsecurity-zerotouch-join] (a IoT version of BRSKI, 758 which uses IDevID and MASA service to facilitate authentication). It 759 is also possible to use EAP methods such as [I-D.ietf-emu-eap-noob] 760 via transports like PANA [RFC5191]. No specific mechanism is 761 specified by this document, as an appropriate mechanism will depend 762 upon deployment circumstances. In some cases, the PLC devices can be 763 deployed in uncontrolled places, where the devices may be accessed 764 physically and be compromised via key extraction. Since the 765 compromised device may be still able to join in the network since its 766 credentials are still valide. When group-shared symmetric keys are 767 used in the network, the consequence is even more severer, i.e., the 768 whole network or a large part of the network is at risk. Thus in 769 scenarios where the physical attacks is considered to be relatively 770 highly possible, per device credentials SHOULD be used. Moreover, 771 additional end-to-end security services" is a complementary to the 772 network side security mechanisms, e.g., if a devices is compromised 773 and it has joined in the network, and then it claims itself as the 774 PANC and try to make the rest devices join its network. In this 775 situation, the real PANC can send an alarm to the operator to 776 acknowledge the risk. Other behavior analysis mechanisms can be 777 deployed to recoginize the malicious PLC devices by inspecting the 778 packets and the data. 780 IP addresses may be used to track devices on the Internet; such 781 devices can often in turn be linked to individuals and their 782 activities. Depending on the application and the actual use pattern, 783 this may be undesirable. To impede tracking, globally unique and 784 non-changing characteristics of IP addresses should be avoided, e.g., 785 by frequently changing the global prefix and avoiding unique link- 786 layer derived IIDs in addresses. [RFC8065] discusses the privacy 787 threats when interface identifiers (IID) are generated without 788 sufficient entropy, including correlation of activities over time, 789 location tracking, device-specific vulnerability exploitation, and 790 address scanning. And an effective way to deal with these threats is 791 to have enough entropy in the IID compairing to the link lifetime. 793 Consider a PLC network with 1024 devices and its link lifetime is 8 794 years, according to the formula in RFC8065, an entropy of 40 bits is 795 sufficient. Padding the short address (12 or 16 bits) to generate 796 the IID of a routable IPv6 address in the public network may be 797 vulnerable to deal with address scans. Thus as suggest in the 798 section 4.1, a hash function can be used to generate a 64 bits IID. 799 When the version number of the PLC network is changed, the IPv6 800 addresses can be changed as well. Other schemes such as limited 801 lease period in DHCPv6 [RFC8415], Cryptographically Generated 802 Addresses (CGAs) [RFC3972], Temporary Address Extensions [RFC8981], 803 Hash-Based Addresses (HBAs) [RFC5535], or semantically opaque 804 addresses [RFC7217] SHOULD be used to enhance the IID privacy. 806 9. Acknowledgements 808 We gratefully acknowledge suggestions from the members of the IETF 809 6lo working group. Great thanks to Samita Chakrabarti and Gabriel 810 Montenegro for their feedback and support in connecting the IEEE and 811 ITU-T sides. The authors thank Scott Mansfield, Ralph Droms, and Pat 812 Kinney for their guidance in the liaison process. The authors wish 813 to thank Stefano Galli, Thierry Lys, Yizhou Li, Yuefeng Wu, and 814 Michael Richardson for their valuable comments and contributions. 816 10. References 818 10.1. Normative References 820 [IEEE_1901.1] 821 IEEE-SA Standards Board, "Standard for Medium Frequency 822 (less than 15 MHz) Power Line Communications for Smart 823 Grid Applications", IEEE 1901.1, May 2018, 824 . 826 [IEEE_1901.2] 827 IEEE-SA Standards Board, "IEEE Standard for Low-Frequency 828 (less than 500 kHz) Narrowband Power Line Communications 829 for Smart Grid Applications", IEEE 1901.2, October 2013, 830 . 833 [ITU-T_G.9903] 834 International Telecommunication Union, "Narrowband 835 orthogonal frequency division multiplexing power line 836 communication transceivers for G3-PLC networks", 837 ITU-T G.9903, February 2014, 838 . 840 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 841 Requirement Levels", BCP 14, RFC 2119, 842 DOI 10.17487/RFC2119, March 1997, 843 . 845 [RFC2464] Crawford, M., "Transmission of IPv6 Packets over Ethernet 846 Networks", RFC 2464, DOI 10.17487/RFC2464, December 1998, 847 . 849 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 850 Architecture", RFC 4291, DOI 10.17487/RFC4291, February 851 2006, . 853 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 854 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 855 DOI 10.17487/RFC4861, September 2007, 856 . 858 [RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler, 859 "Transmission of IPv6 Packets over IEEE 802.15.4 860 Networks", RFC 4944, DOI 10.17487/RFC4944, September 2007, 861 . 863 [RFC6282] Hui, J., Ed. and P. Thubert, "Compression Format for IPv6 864 Datagrams over IEEE 802.15.4-Based Networks", RFC 6282, 865 DOI 10.17487/RFC6282, September 2011, 866 . 868 [RFC6550] Winter, T., Ed., Thubert, P., Ed., Brandt, A., Hui, J., 869 Kelsey, R., Levis, P., Pister, K., Struik, R., Vasseur, 870 JP., and R. Alexander, "RPL: IPv6 Routing Protocol for 871 Low-Power and Lossy Networks", RFC 6550, 872 DOI 10.17487/RFC6550, March 2012, 873 . 875 [RFC6775] Shelby, Z., Ed., Chakrabarti, S., Nordmark, E., and C. 876 Bormann, "Neighbor Discovery Optimization for IPv6 over 877 Low-Power Wireless Personal Area Networks (6LoWPANs)", 878 RFC 6775, DOI 10.17487/RFC6775, November 2012, 879 . 881 [RFC7136] Carpenter, B. and S. Jiang, "Significance of IPv6 882 Interface Identifiers", RFC 7136, DOI 10.17487/RFC7136, 883 February 2014, . 885 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 886 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 887 May 2017, . 889 [RFC8505] Thubert, P., Ed., Nordmark, E., Chakrabarti, S., and C. 890 Perkins, "Registration Extensions for IPv6 over Low-Power 891 Wireless Personal Area Network (6LoWPAN) Neighbor 892 Discovery", RFC 8505, DOI 10.17487/RFC8505, November 2018, 893 . 895 10.2. Informative References 897 [EUI-64] IEEE-SA Standards Board, "Guidelines for 64-bit Global 898 Identifier (EUI-64) Registration Authority", IEEE EUI-64, 899 March 1997, . 902 [I-D.ietf-6tisch-dtsecurity-zerotouch-join] 903 Richardson, M., "6tisch Zero-Touch Secure Join protocol", 904 draft-ietf-6tisch-dtsecurity-zerotouch-join-04 (work in 905 progress), July 2019. 907 [I-D.ietf-6tisch-minimal-security] 908 Vucinic, M., Simon, J., Pister, K., and M. Richardson, 909 "Constrained Join Protocol (CoJP) for 6TiSCH", draft-ietf- 910 6tisch-minimal-security-15 (work in progress), December 911 2019. 913 [I-D.ietf-emu-eap-noob] 914 Aura, T., Sethi, M., and A. Peltonen, "Nimble Out-of-Band 915 Authentication for EAP (EAP-NOOB)", draft-ietf-emu-eap- 916 noob-06 (work in progress), September 2021. 918 [I-D.ietf-roll-aodv-rpl] 919 Anamalamudi, S., Perkins, C. E., Anand, S., and B. Liu, 920 "Supporting Asymmetric Links in Low Power Networks: AODV- 921 RPL", draft-ietf-roll-aodv-rpl-11 (work in progress), 922 September 2021. 924 [IEEE_1901.2a] 925 IEEE-SA Standards Board, "IEEE Standard for Low-Frequency 926 (less than 500 kHz) Narrowband Power Line Communications 927 for Smart Grid Applications - Amendment 1", IEEE 1901.2a, 928 September 2015, . 931 [RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)", 932 RFC 3972, DOI 10.17487/RFC3972, March 2005, 933 . 935 [RFC4963] Heffner, J., Mathis, M., and B. Chandler, "IPv4 Reassembly 936 Errors at High Data Rates", RFC 4963, 937 DOI 10.17487/RFC4963, July 2007, 938 . 940 [RFC5191] Forsberg, D., Ohba, Y., Ed., Patil, B., Tschofenig, H., 941 and A. Yegin, "Protocol for Carrying Authentication for 942 Network Access (PANA)", RFC 5191, DOI 10.17487/RFC5191, 943 May 2008, . 945 [RFC5535] Bagnulo, M., "Hash-Based Addresses (HBA)", RFC 5535, 946 DOI 10.17487/RFC5535, June 2009, 947 . 949 [RFC7217] Gont, F., "A Method for Generating Semantically Opaque 950 Interface Identifiers with IPv6 Stateless Address 951 Autoconfiguration (SLAAC)", RFC 7217, 952 DOI 10.17487/RFC7217, April 2014, 953 . 955 [RFC7925] Tschofenig, H., Ed. and T. Fossati, "Transport Layer 956 Security (TLS) / Datagram Transport Layer Security (DTLS) 957 Profiles for the Internet of Things", RFC 7925, 958 DOI 10.17487/RFC7925, July 2016, 959 . 961 [RFC7973] Droms, R. and P. Duffy, "Assignment of an Ethertype for 962 IPv6 with Low-Power Wireless Personal Area Network 963 (LoWPAN) Encapsulation", RFC 7973, DOI 10.17487/RFC7973, 964 November 2016, . 966 [RFC8036] Cam-Winget, N., Ed., Hui, J., and D. Popa, "Applicability 967 Statement for the Routing Protocol for Low-Power and Lossy 968 Networks (RPL) in Advanced Metering Infrastructure (AMI) 969 Networks", RFC 8036, DOI 10.17487/RFC8036, January 2017, 970 . 972 [RFC8065] Thaler, D., "Privacy Considerations for IPv6 Adaptation- 973 Layer Mechanisms", RFC 8065, DOI 10.17487/RFC8065, 974 February 2017, . 976 [RFC8415] Mrugalski, T., Siodelski, M., Volz, B., Yourtchenko, A., 977 Richardson, M., Jiang, S., Lemon, T., and T. Winters, 978 "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", 979 RFC 8415, DOI 10.17487/RFC8415, November 2018, 980 . 982 [RFC8981] Gont, F., Krishnan, S., Narten, T., and R. Draves, 983 "Temporary Address Extensions for Stateless Address 984 Autoconfiguration in IPv6", RFC 8981, 985 DOI 10.17487/RFC8981, February 2021, 986 . 988 [RFC9010] Thubert, P., Ed. and M. Richardson, "Routing for RPL 989 (Routing Protocol for Low-Power and Lossy Networks) 990 Leaves", RFC 9010, DOI 10.17487/RFC9010, April 2021, 991 . 993 [SCENA] Cano, C., Pittolo, A., Malone, D., and L. Lampe, "State of 994 the Art in Power Line Communications: From the 995 Applications to the Medium", July 2016, 996 . 998 Authors' Addresses 1000 Jianqiang Hou 1001 Huawei Technologies 1002 101 Software Avenue, 1003 Nanjing 210012 1004 China 1006 Email: houjianqiang@huawei.com 1008 Bing Liu 1009 Huawei Technologies 1010 No. 156 Beiqing Rd. Haidian District, 1011 Beijing 100095 1012 China 1014 Email: remy.liubing@huawei.com 1016 Yong-Geun Hong 1017 Daejeon University 1018 62 Daehak-ro, Dong-gu 1019 Daejeon 34520 1020 Korea 1022 Email: yonggeun.hong@gmail.com 1023 Xiaojun Tang 1024 State Grid Electric Power Research Institute 1025 19 Chengxin Avenue 1026 Nanjing 211106 1027 China 1029 Email: itc@sgepri.sgcc.com.cn 1031 Charles E. Perkins 1032 Lupin Lodge 1034 Email: charliep@computer.org