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