idnits 2.17.00 (12 Aug 2021) /tmp/idnits11595/draft-ietf-6lo-plc-10.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 (February 17, 2022) is 86 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-12 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: August 21, 2022 Y-G. Hong 6 Daejeon University 7 X. Tang 8 SGEPRI 9 C. Perkins 10 Lupin Lodge 11 February 17, 2022 13 Transmission of IPv6 Packets over PLC Networks 14 draft-ietf-6lo-plc-10 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 August 21, 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 . . . . . . . 10 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 . . . . . . . . . 17 82 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 83 8. Security Considerations . . . . . . . . . . . . . . . . . . . 17 84 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 19 85 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 19 86 10.1. Normative References . . . . . . . . . . . . . . . . . . 19 87 10.2. Informative References . . . . . . . . . . . . . . . . . 20 88 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23 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 the mesh-under routing scheme. Each PLC node 291 maintains a routing table, in which each route entry comprises the 292 short addresses of the destination and the related next hop. The 293 route entries are built during the network establishment via a 294 pair of association request/confirmation messages. The route 295 entries can be changed via a pair of proxy change request/ 296 confirmation messages. These association and proxy change 297 messages must be approved by the central coordinator (PANC in this 298 document). 300 o LOADng (The Lightweight On-demand Ad hoc Distance vector routing 301 protocol, Next Generation) is a reactive protocol operating at 302 layer-2 or layer-3. Currently, LOADng is supported in ITU-T 303 G.9903 [ITU-T_G.9903], and the IEEE 1901.2 standard refers to 304 ITU-T G.9903 for LOAD-based networks. 306 4. IPv6 over PLC 308 A PLC node distinguishes between an IPv6 PDU and a non-IPv6 PDU based 309 on the equivalent of a EtherType in a layer-2 PLC PDU. [RFC7973] 310 defines a Ethertype of "A0ED" for LoWPAN encapsulation, and this 311 information can be carried in the IE field in the MAC header of 312 [IEEE_1901.2] or [ITU-T_G.9903]. And regarding [IEEE_1901.1], the IP 313 packet type has been defined with the corresponding MAC Service Data 314 Unit (MSDU) type value 49. And the 4-bit Internet Protocol version 315 number in the IP header helps to distinguish between an IPv4 PDU and 316 an IPv6 PDU. 318 6LoWPAN and 6lo standards [RFC4944], [RFC6282], [RFC6775], and 319 [RFC8505] provide useful functionality including link-local IPv6 320 addresses, stateless address auto-configuration, neighbor discovery, 321 header compression, fragmentation, and reassembly. However, due to 322 the different characteristics of the PLC media, the 6LoWPAN 323 adaptation layer, as it is, cannot perfectly fulfill the requirements 324 of PLC environments. These considerations suggest the need for a 325 dedicated adaptation layer for PLC, which is detailed in the 326 following subsections. 328 4.1. Stateless Address Autoconfiguration 330 To obtain an IPv6 Interface Identifier (IID), a PLC device performs 331 stateless address autoconfiguration [RFC4944]. The autoconfiguration 332 can be based on either a long or short link-layer address. 334 The IID can be based on the device's 48-bit MAC address or its EUI-64 335 identifier [EUI-64]. A 48-bit MAC address MUST first be extended to 336 a 64-bit Interface ID by inserting 0xFFFE at the fourth and fifth 337 octets as specified in [RFC2464]. The IPv6 IID is derived from the 338 64-bit Interface ID by inverting the U/L bit [RFC4291]. 340 For IEEE 1901.2 and ITU-T G.9903, a 48-bit "pseudo-address" is formed 341 by the 16-bit PAN ID, 16 zero bits and the 16-bit short address as 342 follows: 344 16_bit_PAN:0000:16_bit_short_address 346 Then, the 64-bit Interface ID MUST be derived by inserting 16-bit 347 0xFFFE into as follows: 349 16_bit_PAN:00FF:FE00:16_bit_short_address 351 For the 12-bit short addresses used by IEEE 1901.1, the 48-bit 352 pseudo-address is formed by 24-bit NID (Network IDentifier, YYYYYY), 353 12 zero bits and a 12-bit TEI (Terminal Equipment Identifier, XXX) as 354 follows: 356 YYYY:YY00:0XXX 358 The 64-bit Interface ID MUST be derived by inserting 16-bit 0xFFFE 359 into this 48-bit pseudo-address as follows: 361 YYYY:YYFF:FE00:0XXX 363 As investigated in [RFC7136], besides [RFC4291], some other IID 364 generation methods defined in IETF do not imply any semantics for the 365 "Universal/Local" (U/L) bit (bit 6) and the Individual/Group bit (bit 366 7), so that these two bits are not reliable indicators for their 367 original meanings. Thus when using an IID derived by a short 368 address, the operators of the PLC network can choose to comply with 369 original meaning of these two bits or not. If so, since the IID 370 derived from the short address is not global, these two bits MUST 371 both be set to zero. In order to avoid any ambiguity in the derived 372 Interface ID, these two bits MUST NOT be used to generate the PANID 373 (for IEEE 1901.2 and ITU-T G.9903) or NID (for IEEE 1901.1). In 374 other words, the PANID or NID MUST always be chosen so that these 375 bits are zeros. If not, the operator must be aware that these two 376 bits are not reliable indicators, and the IID cannot be transformed 377 back into a short link layer address via a reverse operation of the 378 mechanism presented above. 380 For privacy reasons, the IID derived from the MAC address (with 381 padding and bits flipping) SHOULD only be used for link-local address 382 configuration. A PLC host SHOULD use the IID derived from the link- 383 layer short address to configure IPv6 addresses used for 384 communication with the public network; otherwise, the host's MAC 385 address is exposed. As per [RFC8065], when short addresses are used 386 on PLC links, a shared secret key or version number from the 387 Authoritative Border Router Option [RFC6775] can be used to improve 388 the entropy of the hash input, thus the generated IID can be spread 389 out to the full range of the IID address space while stateless 390 address compression is still allowed. The hash algorithm by default 391 of the implementations SHOULD be SHA256, using the version number, 392 the PANID/NID and the short address as the input arguments, and the 393 256-bits hash output is truncated into the IID by taking the high 64 394 bits. 396 4.2. IPv6 Link Local Address 398 The IPv6 link-local address [RFC4291] for a PLC interface is formed 399 by appending the IID, as defined above, to the prefix FE80::/64 (see 400 Figure 2). 402 10 bits 54 bits 64 bits 403 +----------+-----------------------+----------------------------+ 404 |1111111010| (zeros) | Interface Identifier | 405 +----------+-----------------------+----------------------------+ 407 Figure 2: IPv6 Link Local Address for a PLC interface 409 4.3. Unicast Address Mapping 411 The address resolution procedure for mapping IPv6 unicast addresses 412 into PLC link-layer addresses follows the general description in 413 section 7.2 of [RFC4861]. [RFC6775] improves this procedure by 414 eliminating usage of multicast NS. The resolution is realized by the 415 NCEs (neighbor cache entry) created during the address registration 416 at the routers. [RFC8505] further improves the registration 417 procedure by enabling multiple LLNs to form an IPv6 subnet, and by 418 inserting a link-local address registration to better serve proxy 419 registration of new devices. 421 4.3.1. Unicast Address Mapping for IEEE 1901.1 423 The Source/Target Link-layer Address options for IEEE_1901.1 used in 424 the Neighbor Solicitation and Neighbor Advertisement have the 425 following form. 427 0 1 2 3 428 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 429 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 430 | Type | Length=1 | NID : 431 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 432 :NID (continued)| Padding (all zeros) | TEI | 433 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 435 Figure 3: Unicast Address Mapping for IEEE 1901.1 437 Option fields: 439 Type: 1 for Source Link-layer Address and 2 for Target Link-layer 440 Address. 442 Length: The length of this option (including type and length fields) 443 in units of 8 octets. The value of this field is 1 for the 444 12-bit IEEE 1901.1 PLC short addresses. 446 NID: 24-bit Network IDentifier 448 Padding: 12 zero bits 450 TEI: 12-bit Terminal Equipment Identifier 452 4.3.2. Unicast Address Mapping for IEEE 1901.2 and ITU-T G.9903 454 The Source/Target Link-layer Address options for IEEE_1901.2 and 455 ITU-T G.9903 used in the Neighbor Solicitation and Neighbor 456 Advertisement have the following form. 458 0 1 2 3 459 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 460 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 461 | Type | Length=1 | PAN ID | 462 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 463 | Padding (all zeros) | Short Address | 464 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 466 Figure 4: Unicast Address Mapping for IEEE 1901.2 468 Option fields: 470 Type: 1 for Source Link-layer Address and 2 for Target Link-layer 471 Address. 473 Length: The length of this option (including type and length fields) 474 in units of 8 octets. The value of this field is 1 for the 475 16-bit IEEE 1901.2 PLC short addresses. 477 PAN ID: 16-bit PAN IDentifier 479 Padding: 16 zero bits 481 Short Address: 16-bit short address 483 4.4. Neighbor Discovery 485 Neighbor discovery procedures for 6LoWPAN networks are described in 486 Neighbor Discovery Optimization for 6LoWPANs [RFC6775] and [RFC8505]. 487 These optimizations support the registration of sleeping hosts. 488 Although PLC devices are electrically powered, sleeping mode SHOULD 489 still be used for power saving. 491 For IPv6 prefix dissemination, Router Solicitations (RS) and Router 492 Advertisements (RA) MAY be used as per [RFC6775]. If the PLC network 493 uses route-over, the IPv6 prefix MAY be disseminated by the layer-3 494 routing protocol, such as RPL, which may include the prefix in the 495 DIO (DODAG Information Object) message. As per [RFC9010], it is 496 possible to have PLC devices configured as RPL-unaware-leaves, which 497 do not participate in RPL at all, along with RPL-aware PLC devices. 498 In this case, the prefix dissemination SHOULD use the RS/RA messages. 500 For context information dissemination, Router Advertisements (RA) 501 MUST be used as per [RFC6775]. The 6LoWPAN context option (6CO) MUST 502 be included in the RA to disseminate the Context IDs used for prefix 503 and/or address compression. 505 For address registration in route-over mode, a PLC device MUST 506 register its addresses by sending a unicast link-local Neighbor 507 Solicitation to the 6LR. If the registered address is link-local, 508 the 6LR SHOULD NOT further register it to the registrar (6LBR, 6BBR). 509 Otherwise, the address MUST be registered via an ARO or EARO included 510 in the DAR ([RFC6775]) or EDAR ([RFC8505]) messages. For RFC8505 511 compliant PLC devices, the 'R' flag in the EARO MUST be set when 512 sending Neighbor Solicitations in order to extract the status 513 information in the replied Neighbor Advertisements from the 6LR. If 514 DHCPv6 is used to assign addresses or the IPv6 address is derived 515 from unique long or short link layer address, Duplicate Address 516 Detection (DAD) SHOULD NOT be utilized. Otherwise, the DAD MUST be 517 performed at the 6LBR (as per [RFC6775]) or proxied by the routing 518 registrar (as per [RFC8505]). The registration status is fed back 519 via the DAC or EDAC message from the 6LBR and the Neighbor 520 Advertisement (NA) from the 6LR. The section 6 of [RFC8505] how 521 RFC6775-only devices work with RFC8505-updated devices. 523 For address registration in mesh-under mode, since all the PLC 524 devices are link-local neighbors to the 6LBR, DAR/DAC or EDAR/EDAC 525 messages are not required. A PLC device MUST register its addresses 526 by sending a unicast NS message with an ARO or EARO. The 527 registration status is fed back via the NA message from the 6LBR. 529 4.5. Header Compression 531 The compression of IPv6 datagrams within PLC MAC frames refers to 532 [RFC6282], which updates [RFC4944]. Header compression as defined in 533 [RFC6282] which specifies the compression format for IPv6 datagrams 534 on top of IEEE 802.15.4, is the basis for IPv6 header compression in 535 PLC. For situations when PLC MAC MTU cannot support the 1280-octet 536 IPv6 packet, headers MUST be compressed according to [RFC6282] 537 encoding formats, including the Dispatch Header, the LOWPAN_IPHC and 538 the compression residu carried in-line. 540 For IEEE 1901.2 and G.9903, the IP header compression follows the 541 instruction in [RFC6282]. However, additional adaptation MUST be 542 considered for IEEE 1901.1 since it has a short address of 12 bits 543 instead of 16 bits. The only modification is the semantics of the 544 "Source Address Mode" and the "Dstination Address Mode" when set as 545 "10" in the section 3.1 of [RFC6282], which is illustrated as 546 following. 548 SAM: Source Address Mode: 550 If SAC=0: Stateless compression 551 10: 16 bits. The first 112 bits of the address are elided. The 552 value of the first 64 bits is the link-local prefix padded with 553 zeros. The following 64 bits are 0000:00ff:fe00:0XXX, where 554 0XXX are the 16 bits carried in-line. 556 If SAC=1: stateful context-based compression 558 10: 16 bits. The address is derived using context information and 559 the 16 bits carried in-line. Bits covered by context 560 information are always used. Any IID bits not covered by 561 context information are taken directly from their corresponding 562 bits in the 16-bit to IID mapping given by 0000:00ff:fe00:0XXX, 563 where 0XXX are the 16 bits carried inline. Any remaining bits 564 are zero. 566 DAM: Destination Address Mode: 568 If M=0 and DAC=0: Stateless compression 570 10: 16 bits. The first 112 bits of the address are elided. The 571 value of the first 64 bits is the link-local prefix padded with 572 zeros. The following 64 bits are 0000:00ff: fe00:0XXX, where 573 0XXX are the 16 bits carried in-line. 575 If M=0 and DAC=1: stateful context-based compression 577 10: 16 bits. The address is derived using context information and 578 the 16 bits carried in-line. Bits covered by context 579 information are always used. Any IID bits not covered by 580 context information are taken directly from their corresponding 581 bits in the 16-bit to IID mapping given by 0000:00ff:fe00:0XXX, 582 where XXXX are the 16 bits carried in- line. Any remaining 583 bits are zero. 585 4.6. Fragmentation and Reassembly 587 The constrained PLC MAC layer provides the function of fragmentation 588 and reassembly. However, fragmentation and reassembly is still 589 required at the adaptation layer, if the MAC layer cannot support the 590 minimum MTU demanded by IPv6, which is 1280 octets. 592 In IEEE 1901.1 and IEEE 1901.2, the MAC layer supports payloads as 593 big as 2031 octets and 1576 octets respectively. However, when the 594 channel condition is noisy, smaller packets have higher transmission 595 success rate, the operator can choose to configure smaller MTU at the 596 MAC layer. If the configured MTU is smaller than 1280 octets, the 597 fragmentation and reassembly defined in [RFC4944] MUST be used. 599 In ITU-T G.9903, the maximum MAC payload size is fixed to 400 octets, 600 so to cope with the required MTU of 1280 octets by IPv6, 601 fragmentation and reassembly at the 6lo adaptation layer MUST be 602 provided as specified in [RFC4944]. 604 [RFC4944] uses a 16-bit datagram tag to identify the fragments of the 605 same IP packet. [RFC4963] specifies that at high data rates, the 606 16-bit IP identification field is not large enough to prevent 607 frequent incorrectly assembled IP fragments. For constrained PLC, 608 the data rate is much lower than the situation mentioned in RFC4963, 609 thus the 16-bit tag is sufficient to assemble the fragments 610 correctly. 612 5. Internet Connectivity Scenarios and Topologies 614 The PLC network model can be simplified to two kinds of network 615 device: PAN Coordinator (PANC) and PLC Device. The PANC is the 616 primary coordinator of the PLC subnet and can be seen as a primary 617 node; PLC Devices are typically PLC meters and sensors. The address 618 registration and DAD features can also be deployed on the PANC, for 619 example the 6LBR [RFC6775] or the routing registrar in [RFC8505]. 620 IPv6 over PLC networks are built as trees, meshes or stars topology 621 according to the use cases. Generally, each PLC network has one 622 PANC. In some cases, the PLC network can have alternate coordinators 623 to replace the PANC when the PANC leaves the network for some reason. 624 Note that the PLC topologies in this section are based on logical 625 connectivity, not physical links. The term "PLC subnet" refers to a 626 multilink subnet, in which the PLC devices share the same address 627 prefix. 629 The star topology is common in current PLC scenarios. In single-hop 630 star topologies, communication at the link layer only takes place 631 between a PLC Device and a PANC. The PANC typically collects data 632 (e.g., a meter reading) from the PLC devices, and then concentrates 633 and uploads the data through Ethernet or Cellular networks (see 634 Figure 5). The collected data is transmitted by the smart meters 635 through PLC, aggregated by a concentrator, sent to the utility and 636 then to a Meter Data Management System for data storage, analysis and 637 billing. This topology has been widely applied in the deployment of 638 smart meters, especially in apartment buildings. 640 PLC Device PLC Device 641 \ / +--------- 642 \ / / 643 \ / + 644 \ / | 645 PLC Device ------ PANC ===========+ Internet 646 / \ | 647 / \ + 648 / \ \ 649 / \ +--------- 650 PLC Device PLC Device 652 <----------------------> 653 PLC subnet (IPv6 over PLC) 655 Figure 5: PLC Star Network connected to the Internet 657 A tree topology is useful when the distance between a device A and 658 the PANC is beyond the PLC allowed limit and there is another device 659 B in between able to communicate with both sides. Device B in this 660 case acts both as a PLC Device and a Coordinator. For this scenario, 661 the link layer communications take place between device A and device 662 B, and between device B and PANC. An example of a PLC tree network 663 is depicted in Figure 6. This topology can be applied in smart 664 street lighting, where the lights adjust the brightness to reduce 665 energy consumption while sensors are deployed on the street-lights to 666 provide information such as light intensity, temperature, and 667 humidity. The data transmission distance in the street lighting 668 scenario is normally above several kilometers, thus a PLC tree 669 network is required. A more sophisticated AMI network may also be 670 constructed into the tree topology which is depicted in [RFC8036]. A 671 tree topology is suitable for AMI scenarios that require large 672 coverage but low density, e.g., the deployment of smart meters in 673 rural areas. RPL is suitable for maintenance of a tree topology in 674 which there is no need for communication directly between PAN 675 devices. 677 PLC Device 678 \ +--------- 679 PLC Device A \ / 680 \ \ + 681 \ \ | 682 PLC Device B -- PANC ===========+ Internet 683 / / | 684 / / + 685 PLC Device---PLC Device / \ 686 / +--------- 687 PLC Device---PLC Device 689 <-------------------------> 690 PLC subnet (IPv6 over PLC) 692 Figure 6: PLC Tree Network connected to the Internet 694 Mesh networking in PLC is of great potential applications and has 695 been studied for several years. By connecting all nodes with their 696 neighbors in communication range (see Figure 7), a mesh topology 697 dramatically enhances the communication efficiency and thus expands 698 the size of PLC networks. A simple use case is the smart home 699 scenario where the ON/OFF state of air conditioning is controlled by 700 the state of home lights (ON/OFF) and doors (OPEN/CLOSE). AODV-RPL 701 ([I-D.ietf-roll-aodv-rpl]) enables direct PLC device to PLC device 702 communication, without being obliged to transmit frames through the 703 PANC, which is a requirement often cited for AMI infrastructure. 705 PLC Device---PLC Device 706 / \ / \ +--------- 707 / \ / \ / 708 / \ / \ + 709 / \ / \ | 710 PLC Device--PLC Device---PANC ===========+ Internet 711 \ / \ / | 712 \ / \ / + 713 \ / \ / \ 714 \ / \ / +--------- 715 PLC Device---PLC Device 717 <-------------------------------> 718 PLC subnet (IPv6 over PLC) 720 Figure 7: PLC Mesh Network connected to the Internet 722 6. Operations and Manageability Considerations 724 The constrained PLC networks are not managed in the same way as an 725 enterprise network or a carrier network. Constrained PLC networks, 726 like the other IoT networks, are designed to be self-organized and 727 self-managed. The software or firmware is flashed into the devices 728 before deployment by the vendor or operator. And during the 729 deployment process, the devices are bootstrapped, and no extra 730 configuration is needed to get the devices connected to each other. 731 Once a device becomes offline, it goes back to the bootstrapping 732 stage and tries to rejoin the network. The onboarding status of the 733 devices and the topology of the PLC network can be visualized via the 734 PANC. The recently-formed iotops WG in IETF is aiming to identify 735 the requirements in IoT network management, and operational practices 736 will be published. Developers and operators of PLC networks should 737 be able to learn operational experiences from this WG. 739 7. IANA Considerations 741 There are no IANA considerations related to this document. 743 8. Security Considerations 745 Due to the high accessibility of power grids, PLC might be 746 susceptible to eavesdropping within its communication coverage, e.g., 747 one apartment tenant may have the chance to monitor the other smart 748 meters in the same apartment building. Link layer security 749 mechanisms, such as payload encryption and devcie authentication, are 750 designed in the PLC technologies mentioned in this document. 751 Additionally, on-path malicious PLC device could eavesdrop or modify 752 packets sent through it if appropriate confidentiality and integrity 753 mechanisms are not implemented. 755 Malicious PLC devices could paralyze the whole network via DOS 756 attacks, e.g., keep joining and leaving the network frequently, or 757 sending multicast routing messages containing fake metrics. A device 758 may also inadvertently join a wrong or even malicious network, 759 exposing its data to malicious users. When communicating with a 760 device outside the PLC network, the traffic has to go through the 761 PANC. Thus the PANC must be a trusted entity. Moreover, the PLC 762 network must prevent malicious devices to join in the network. Thus 763 Mutual authentication of a PLC network and a new device is important, 764 and it can be conducted during the onboarding process of the new 765 device. Methods include protocols such as [RFC7925] (exchanging pre- 766 installed certificates over DTLS), [I-D.ietf-6tisch-minimal-security] 767 (which uses pre-shared keys), and 768 [I-D.ietf-6tisch-dtsecurity-zerotouch-join] (a IoT version of BRSKI, 769 which uses IDevID and MASA service to facilitate authentication). It 770 is also possible to use EAP methods such as [I-D.ietf-emu-eap-noob] 771 via transports like PANA [RFC5191]. No specific mechanism is 772 specified by this document, as an appropriate mechanism will depend 773 upon deployment circumstances. In some cases, the PLC devices can be 774 deployed in uncontrolled places, where the devices may be accessed 775 physically and be compromised via key extraction. Since the 776 compromised device may be still able to join in the network since its 777 credentials are still valide. When group-shared symmetric keys are 778 used in the network, the consequence is even more severer, i.e., the 779 whole network or a large part of the network is at risk. Thus in 780 scenarios where the physical attacks is considered to be relatively 781 highly possible, per device credentials SHOULD be used. Moreover, 782 additional end-to-end security services" is a complementary to the 783 network side security mechanisms, e.g., if a devices is compromised 784 and it has joined in the network, and then it claims itself as the 785 PANC and try to make the rest devices join its network. In this 786 situation, the real PANC can send an alarm to the operator to 787 acknowledge the risk. Other behavior analysis mechanisms can be 788 deployed to recoginize the malicious PLC devices by inspecting the 789 packets and the data. 791 IP addresses may be used to track devices on the Internet; such 792 devices can often in turn be linked to individuals and their 793 activities. Depending on the application and the actual use pattern, 794 this may be undesirable. To impede tracking, globally unique and 795 non-changing characteristics of IP addresses should be avoided, e.g., 796 by frequently changing the global prefix and avoiding unique link- 797 layer derived IIDs in addresses. [RFC8065] discusses the privacy 798 threats when interface identifiers (IID) are generated without 799 sufficient entropy, including correlation of activities over time, 800 location tracking, device-specific vulnerability exploitation, and 801 address scanning. And an effective way to deal with these threats is 802 to have enough entropy in the IID compairing to the link lifetime. 803 Consider a PLC network with 1024 devices and its link lifetime is 8 804 years, according to the formula in RFC8065, an entropy of 40 bits is 805 sufficient. Padding the short address (12 or 16 bits) to generate 806 the IID of a routable IPv6 address in the public network may be 807 vulnerable to deal with address scans. Thus as suggest in the 808 section 4.1, a hash function can be used to generate a 64 bits IID. 809 When the version number of the PLC network is changed, the IPv6 810 addresses can be changed as well. Other schemes such as limited 811 lease period in DHCPv6 [RFC8415], Cryptographically Generated 812 Addresses (CGAs) [RFC3972], Temporary Address Extensions [RFC8981], 813 Hash-Based Addresses (HBAs) [RFC5535], or semantically opaque 814 addresses [RFC7217] SHOULD be used to enhance the IID privacy. 816 9. Acknowledgements 818 We gratefully acknowledge suggestions from the members of the IETF 819 6lo working group. Great thanks to Samita Chakrabarti and Gabriel 820 Montenegro for their feedback and support in connecting the IEEE and 821 ITU-T sides. The authors thank Scott Mansfield, Ralph Droms, and Pat 822 Kinney for their guidance in the liaison process. The authors wish 823 to thank Stefano Galli, Thierry Lys, Yizhou Li, Yuefeng Wu, and 824 Michael Richardson for their valuable comments and contributions. 826 10. References 828 10.1. Normative References 830 [IEEE_1901.1] 831 IEEE-SA Standards Board, "Standard for Medium Frequency 832 (less than 15 MHz) Power Line Communications for Smart 833 Grid Applications", IEEE 1901.1, May 2018, 834 . 836 [IEEE_1901.2] 837 IEEE-SA Standards Board, "IEEE Standard for Low-Frequency 838 (less than 500 kHz) Narrowband Power Line Communications 839 for Smart Grid Applications", IEEE 1901.2, October 2013, 840 . 843 [ITU-T_G.9903] 844 International Telecommunication Union, "Narrowband 845 orthogonal frequency division multiplexing power line 846 communication transceivers for G3-PLC networks", 847 ITU-T G.9903, February 2014, 848 . 850 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 851 Requirement Levels", BCP 14, RFC 2119, 852 DOI 10.17487/RFC2119, March 1997, 853 . 855 [RFC2464] Crawford, M., "Transmission of IPv6 Packets over Ethernet 856 Networks", RFC 2464, DOI 10.17487/RFC2464, December 1998, 857 . 859 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 860 Architecture", RFC 4291, DOI 10.17487/RFC4291, February 861 2006, . 863 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 864 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 865 DOI 10.17487/RFC4861, September 2007, 866 . 868 [RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler, 869 "Transmission of IPv6 Packets over IEEE 802.15.4 870 Networks", RFC 4944, DOI 10.17487/RFC4944, September 2007, 871 . 873 [RFC6282] Hui, J., Ed. and P. Thubert, "Compression Format for IPv6 874 Datagrams over IEEE 802.15.4-Based Networks", RFC 6282, 875 DOI 10.17487/RFC6282, September 2011, 876 . 878 [RFC6550] Winter, T., Ed., Thubert, P., Ed., Brandt, A., Hui, J., 879 Kelsey, R., Levis, P., Pister, K., Struik, R., Vasseur, 880 JP., and R. Alexander, "RPL: IPv6 Routing Protocol for 881 Low-Power and Lossy Networks", RFC 6550, 882 DOI 10.17487/RFC6550, March 2012, 883 . 885 [RFC6775] Shelby, Z., Ed., Chakrabarti, S., Nordmark, E., and C. 886 Bormann, "Neighbor Discovery Optimization for IPv6 over 887 Low-Power Wireless Personal Area Networks (6LoWPANs)", 888 RFC 6775, DOI 10.17487/RFC6775, November 2012, 889 . 891 [RFC7136] Carpenter, B. and S. Jiang, "Significance of IPv6 892 Interface Identifiers", RFC 7136, DOI 10.17487/RFC7136, 893 February 2014, . 895 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 896 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 897 May 2017, . 899 [RFC8505] Thubert, P., Ed., Nordmark, E., Chakrabarti, S., and C. 900 Perkins, "Registration Extensions for IPv6 over Low-Power 901 Wireless Personal Area Network (6LoWPAN) Neighbor 902 Discovery", RFC 8505, DOI 10.17487/RFC8505, November 2018, 903 . 905 10.2. Informative References 907 [EUI-64] IEEE-SA Standards Board, "Guidelines for 64-bit Global 908 Identifier (EUI-64) Registration Authority", IEEE EUI-64, 909 March 1997, . 912 [I-D.ietf-6tisch-dtsecurity-zerotouch-join] 913 Richardson, M., "6tisch Zero-Touch Secure Join protocol", 914 draft-ietf-6tisch-dtsecurity-zerotouch-join-04 (work in 915 progress), July 2019. 917 [I-D.ietf-6tisch-minimal-security] 918 Vucinic, M., Simon, J., Pister, K., and M. Richardson, 919 "Constrained Join Protocol (CoJP) for 6TiSCH", draft-ietf- 920 6tisch-minimal-security-15 (work in progress), December 921 2019. 923 [I-D.ietf-emu-eap-noob] 924 Aura, T., Sethi, M., and A. Peltonen, "Nimble Out-of-Band 925 Authentication for EAP (EAP-NOOB)", draft-ietf-emu-eap- 926 noob-06 (work in progress), September 2021. 928 [I-D.ietf-roll-aodv-rpl] 929 Perkins, C. E., Anand, S., Anamalamudi, S., and B. Liu, 930 "Supporting Asymmetric Links in Low Power Networks: AODV- 931 RPL", draft-ietf-roll-aodv-rpl-12 (work in progress), 932 January 2022. 934 [IEEE_1901.2a] 935 IEEE-SA Standards Board, "IEEE Standard for Low-Frequency 936 (less than 500 kHz) Narrowband Power Line Communications 937 for Smart Grid Applications - Amendment 1", IEEE 1901.2a, 938 September 2015, . 941 [RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)", 942 RFC 3972, DOI 10.17487/RFC3972, March 2005, 943 . 945 [RFC4963] Heffner, J., Mathis, M., and B. Chandler, "IPv4 Reassembly 946 Errors at High Data Rates", RFC 4963, 947 DOI 10.17487/RFC4963, July 2007, 948 . 950 [RFC5191] Forsberg, D., Ohba, Y., Ed., Patil, B., Tschofenig, H., 951 and A. Yegin, "Protocol for Carrying Authentication for 952 Network Access (PANA)", RFC 5191, DOI 10.17487/RFC5191, 953 May 2008, . 955 [RFC5535] Bagnulo, M., "Hash-Based Addresses (HBA)", RFC 5535, 956 DOI 10.17487/RFC5535, June 2009, 957 . 959 [RFC7217] Gont, F., "A Method for Generating Semantically Opaque 960 Interface Identifiers with IPv6 Stateless Address 961 Autoconfiguration (SLAAC)", RFC 7217, 962 DOI 10.17487/RFC7217, April 2014, 963 . 965 [RFC7925] Tschofenig, H., Ed. and T. Fossati, "Transport Layer 966 Security (TLS) / Datagram Transport Layer Security (DTLS) 967 Profiles for the Internet of Things", RFC 7925, 968 DOI 10.17487/RFC7925, July 2016, 969 . 971 [RFC7973] Droms, R. and P. Duffy, "Assignment of an Ethertype for 972 IPv6 with Low-Power Wireless Personal Area Network 973 (LoWPAN) Encapsulation", RFC 7973, DOI 10.17487/RFC7973, 974 November 2016, . 976 [RFC8036] Cam-Winget, N., Ed., Hui, J., and D. Popa, "Applicability 977 Statement for the Routing Protocol for Low-Power and Lossy 978 Networks (RPL) in Advanced Metering Infrastructure (AMI) 979 Networks", RFC 8036, DOI 10.17487/RFC8036, January 2017, 980 . 982 [RFC8065] Thaler, D., "Privacy Considerations for IPv6 Adaptation- 983 Layer Mechanisms", RFC 8065, DOI 10.17487/RFC8065, 984 February 2017, . 986 [RFC8415] Mrugalski, T., Siodelski, M., Volz, B., Yourtchenko, A., 987 Richardson, M., Jiang, S., Lemon, T., and T. Winters, 988 "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", 989 RFC 8415, DOI 10.17487/RFC8415, November 2018, 990 . 992 [RFC8981] Gont, F., Krishnan, S., Narten, T., and R. Draves, 993 "Temporary Address Extensions for Stateless Address 994 Autoconfiguration in IPv6", RFC 8981, 995 DOI 10.17487/RFC8981, February 2021, 996 . 998 [RFC9010] Thubert, P., Ed. and M. Richardson, "Routing for RPL 999 (Routing Protocol for Low-Power and Lossy Networks) 1000 Leaves", RFC 9010, DOI 10.17487/RFC9010, April 2021, 1001 . 1003 [SCENA] Cano, C., Pittolo, A., Malone, D., and L. Lampe, "State of 1004 the Art in Power Line Communications: From the 1005 Applications to the Medium", July 2016, 1006 . 1008 Authors' Addresses 1010 Jianqiang Hou 1011 Huawei Technologies 1012 101 Software Avenue, 1013 Nanjing 210012 1014 China 1016 Email: houjianqiang@huawei.com 1018 Bing Liu 1019 Huawei Technologies 1020 No. 156 Beiqing Rd. Haidian District, 1021 Beijing 100095 1022 China 1024 Email: remy.liubing@huawei.com 1026 Yong-Geun Hong 1027 Daejeon University 1028 62 Daehak-ro, Dong-gu 1029 Daejeon 34520 1030 Korea 1032 Email: yonggeun.hong@gmail.com 1034 Xiaojun Tang 1035 State Grid Electric Power Research Institute 1036 19 Chengxin Avenue 1037 Nanjing 211106 1038 China 1040 Email: itc@sgepri.sgcc.com.cn 1042 Charles E. Perkins 1043 Lupin Lodge 1045 Email: charliep@computer.org