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