idnits 2.17.00 (12 Aug 2021) /tmp/idnits1409/draft-ietf-6lo-plc-06.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 (April 20, 2021) is 396 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-08 == Outdated reference: draft-ietf-roll-unaware-leaves has been published as RFC 9010 -- Obsolete informational reference (is this intentional?): RFC 3315 (Obsoleted by RFC 8415) -- Obsolete informational reference (is this intentional?): RFC 4941 (Obsoleted by RFC 8981) Summary: 0 errors (**), 0 flaws (~~), 6 warnings (==), 3 comments (--). 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: October 22, 2021 Y-G. Hong 6 ETRI 7 X. Tang 8 SGEPRI 9 C. Perkins 10 Lupin Lodge 11 April 20, 2021 13 Transmission of IPv6 Packets over PLC Networks 14 draft-ietf-6lo-plc-06 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 inherent advantage of existing 22 electricity infrastructure facilitates the expansion of PLC 23 deployments, and moreover, a wide variety of accessible devices 24 raises the potential demand of IPv6 for future applications. This 25 document describes how IPv6 packets are transported over constrained 26 PLC networks, such as ITU-T G.9903, IEEE 1901.1 and IEEE 1901.2. 28 Status of This Memo 30 This Internet-Draft is submitted in full conformance with the 31 provisions of BCP 78 and BCP 79. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF). Note that other groups may also distribute 35 working documents as Internet-Drafts. The list of current Internet- 36 Drafts is at https://datatracker.ietf.org/drafts/current/. 38 Internet-Drafts are draft documents valid for a maximum of six months 39 and may be updated, replaced, or obsoleted by other documents at any 40 time. It is inappropriate to use Internet-Drafts as reference 41 material or to cite them other than as "work in progress." 43 This Internet-Draft will expire on October 22, 2021. 45 Copyright Notice 47 Copyright (c) 2021 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents 52 (https://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with respect 55 to this document. Code Components extracted from this document must 56 include Simplified BSD License text as described in Section 4.e of 57 the Trust Legal Provisions and are provided without warranty as 58 described in the Simplified BSD License. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 63 2. Requirements Notation and Terminology . . . . . . . . . . . . 3 64 3. Overview of PLC . . . . . . . . . . . . . . . . . . . . . . . 5 65 3.1. Protocol Stack . . . . . . . . . . . . . . . . . . . . . 5 66 3.2. Addressing Modes . . . . . . . . . . . . . . . . . . . . 6 67 3.3. Maximum Transmission Unit . . . . . . . . . . . . . . . . 6 68 3.4. Routing Protocol . . . . . . . . . . . . . . . . . . . . 7 69 4. IPv6 over PLC . . . . . . . . . . . . . . . . . . . . . . . . 7 70 4.1. Stateless Address Autoconfiguration . . . . . . . . . . . 8 71 4.2. IPv6 Link Local Address . . . . . . . . . . . . . . . . . 9 72 4.3. Unicast Address Mapping . . . . . . . . . . . . . . . . . 9 73 4.3.1. Unicast Address Mapping for IEEE 1901.1 . . . . . . . 9 74 4.3.2. Unicast Address Mapping for IEEE 1901.2 and ITU-T 75 G.9903 . . . . . . . . . . . . . . . . . . . . . . . 10 76 4.4. Neighbor Discovery . . . . . . . . . . . . . . . . . . . 11 77 4.5. Header Compression . . . . . . . . . . . . . . . . . . . 12 78 4.6. Fragmentation and Reassembly . . . . . . . . . . . . . . 12 79 5. Internet Connectivity Scenarios and Topologies . . . . . . . 13 80 6. Operations and Manageability Considerations . . . . . . . . . 16 81 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 82 8. Security Consideration . . . . . . . . . . . . . . . . . . . 16 83 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 17 84 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 85 10.1. Normative References . . . . . . . . . . . . . . . . . . 17 86 10.2. Informative References . . . . . . . . . . . . . . . . . 19 87 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21 89 1. Introduction 91 The idea of using power lines for both electricity supply and 92 communication can be traced back to the beginning of the last 93 century. With the advantage of existing power grid, Power Line 94 Communication (PLC) is a good candidate for supporting various 95 service scenarios such as in houses and offices, in trains and 96 vehicles, in smart grid and advanced metering infrastructure (AMI) 97 [SCENA]. The data acquisition devices in these scenarios share 98 common features such as fixed position, large quantity, low data rate 99 and low power consumption. 101 Although PLC technology has evolved over several decades, it has not 102 been fully adapted for IPv6 based constrained networks. The 103 resource-constrained IoT related scenarios lie in the low voltage PLC 104 networks with most applications in the area of Advanced Metering 105 Infrastructure (AMI), Vehicle-to-Grid communications, in-home energy 106 management and smart street lighting. IPv6 is important for PLC 107 networks, due to its large address space and efficent address auto- 108 configuration. 110 This document provides a brief overview of PLC technologies. Some of 111 them have LLN (low power and lossy network) characteristics, i.e. 112 limited power consumption, memory and processing resources. This 113 document specifies the transmission of IPv6 packets over those 114 "constrained" PLC networks. The general approach is to adapt 115 elements of the 6LoWPAN (IPv6 over Low-Power Wireless Personal Area 116 Network) and 6lo (IPv6 over Networks of Resource-constrained Nodes) 117 specifications, such as [RFC4944], [RFC6282], [RFC6775] and [RFC8505] 118 to constrained PLC networks. 120 2. Requirements Notation and Terminology 122 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 123 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 124 "OPTIONAL" in this document are to be interpreted as described in 125 BCP14 [RFC2119] [RFC8174] when, and only when, they appear in all 126 capitals, as shown here. 128 This document uses the following acronyms and terminologies: 130 6LoWPAN: IPv6 over Low-Power Wireless Personal Area Network 132 6lo: IPv6 over Networks of Resource-constrained Nodes 134 AMI: Advanced Metering Infrastructure 136 BBPLC: Broadband Power Line Communication 137 CID: Context ID 139 Coordinator: A device capable of relaying messages. 141 DAD: Duplicate Address Detection 143 EV: Electric Vehicle 145 IID: IPv6 Interface Identifier 147 IPHC: IP Header Compression 149 LAN: Local Area Network 151 LLN: Low power and Lossy Network 153 MSDU: MAC Service Data Unit 155 MTU: Maximum Transmission Unit 157 NBPLC: Narrowband Power Line Communication 159 OFDM: Orthogonal Frequency Division Multiplexing 161 PANC: PAN Coordinator, a coordinator which also acts as the primary 162 controller of a PAN. 164 PLC: Power Line Communication 166 PLC device: An entity that follows the PLC standards and implements 167 the protocol stack described in this draft. 169 PSDU: PHY Service Data Unit 171 RPL: IPv6 Routing Protocol for Low-Power and Lossy Networks 173 RA: Router Advertisement 175 WAN: Wide Area Network 176 The terminology used in this draft is aligned with IEEE 1901.2 178 +---------------+----------------+------------------+---------------+ 179 | IEEE 1901.2 | IEEE 1901.1 | ITU-T G.9903 | This document | 180 +---------------+----------------+------------------+---------------+ 181 | PAN | Central | PAN Coordinator | PAN | 182 | Coordinator | Coordinator | | Coordinator | 183 | | | | | 184 | Coordinator | Proxy | Full-function | Coordinator | 185 | | Coordinator | device | | 186 | | | | | 187 | Device | Station | PAN Device | PLC Device | 188 +---------------+----------------+------------------+---------------+ 190 Table 1: Terminology Mapping between PLC standards 192 3. Overview of PLC 194 PLC technology enables convenient two-way communications for home 195 users and utility companies to monitor and control electric plugged 196 devices such as electricity meters and street lights. Due to the 197 large range of communication frequencies, PLC is generally classified 198 into two categories: Narrowband PLC (NBPLC) for automation of sensors 199 (which have low frequency band and low power cost), and Broadband PLC 200 (BBPLC) for home and industry networking applications. 202 Various standards have been addressed on the MAC and PHY layers for 203 this communication technology, e.g., BBPLC (1.8-250 MHz) including 204 IEEE 1901 and ITU-T G.hn, and NBPLC (3-500 kHz) including ITU-T 205 G.9902 (G.hnem), ITU-T G.9903 (G3-PLC) [ITU-T_G.9903], ITU-T G.9904 206 (PRIME), IEEE 1901.2 [IEEE_1901.2] (combination of G3-PLC and PRIME 207 PLC) and IEEE 1901.2a [IEEE_1901.2a] (an amendment to IEEE 1901.2). 209 A new PLC standard IEEE 1901.1 [IEEE_1901.1], which aims at the 210 medium frequency band of less than 12 MHz, has been published by the 211 IEEE standard for Smart Grid Powerline Communication Working Group 212 (SGPLC WG). IEEE 1901.1 balances the needs for bandwidth versus 213 communication range, and is thus a promising option for 6lo 214 applications. 216 This specification is focused on IEEE 1901.1, IEEE 1901.2 and ITU-T 217 G.9903. 219 3.1. Protocol Stack 221 The protocol stack for IPv6 over PLC is illustrated in Figure 1. The 222 PLC MAC/PHY layer corresponds to IEEE 1901.1, IEEE 1901.2 or ITU-T 223 G.9903. The 6lo adaptation layer for PLC is illustrated in 224 Section 4. For multihop tree and mesh topologies, a routing protocol 225 is likely to be necessary. The routes can be built in mesh-under 226 mode at layer 2 or in route-over mode at layer 3, as explained in 227 Section 3.4. 229 +----------------------------------------+ 230 | Application Layer | 231 +----------------------------------------+ 232 | TCP/UDP | 233 +----------------------------------------+ 234 | | 235 | IPv6 | 236 | | 237 +----------------------------------------+ 238 | Adaptation layer for IPv6 over PLC | 239 +----------------------------------------+ 240 | PLC MAC Layer | 241 +----------------------------------------+ 242 | PLC PHY Layer | 243 +----------------------------------------+ 245 Figure 1: PLC Protocol Stack 247 3.2. Addressing Modes 249 Each PLC device has a globally unique long address of 48-bit 250 ([IEEE_1901.1]) or 64-bit ([IEEE_1901.2], [ITU-T_G.9903]) and a short 251 address of 12-bit ([IEEE_1901.1]) or 16-bit ([IEEE_1901.2], 252 [ITU-T_G.9903]). The long address is set by the manufacturer 253 according to the IEEE EUI-48 MAC address or the IEEE EUI-64 address. 254 Each PLC device joins the network by using the long address and 255 communicates with other devices by using the short address after 256 joining the network. Short addresses can be assigned during the 257 onboarding process, by the PANC or the JRC (join registrar/ 258 coordinator) in CoJP (Constrained Join Protocol) 259 [I-D.ietf-6tisch-minimal-security]. 261 3.3. Maximum Transmission Unit 263 The Maximum Transmission Unit (MTU) of the MAC layer determines 264 whether fragmentation and reassembly are needed at the adaptation 265 layer of IPv6 over PLC. IPv6 requires an MTU of 1280 octets or 266 greater; thus for a MAC layer with MTU lower than this limit, 267 fragmentation and reassembly at the adaptation layer are required. 269 The IEEE 1901.1 MAC supports upper layer packets up to 2031 octets. 270 The IEEE 1901.2 MAC layer supports the MTU of 1576 octets (the 271 original value of 1280 bytes was updated in 2015 [IEEE_1901.2a]). 273 Though these two technologies can support IPv6 natively without 274 fragmentation and reassembly, it is possible to configure a smaller 275 MTU in high-noise communication environment. Thus the 6lo functions, 276 including header compression, fragmentation and reassembly, are still 277 applicable and useful. 279 The MTU for ITU-T G.9903 is 400 octets, insufficient for supporting 280 IPv6's MTU. For this reason, fragmentation and reassembly is 281 required for G.9903-based networks to adapt IPv6. 283 3.4. Routing Protocol 285 Routing protocols suitable for use in PLC networks include: 287 o RPL (Routing Protocol for Low-Power and Lossy Networks) [RFC6550] 288 is a layer 3 routing protocol. AODV-RPL [I-D.ietf-roll-aodv-rpl] 289 updates RPL to include reactive, point-to-point, and asymmetric 290 routing. IEEE 1901.2 specifies Information Elements (IEs) with 291 MAC layer metrics, which can be provided to L3 routing protocol 292 for parent selection. 294 o IEEE 1901.1 supports L2 routing. Each PLC node maintains a L2 295 routing table, in which each route entry comprises the short 296 addresses of the destination and the related next hop. The route 297 entries are built during the network establishment via a pair of 298 association request/confirmation messages. The route entries can 299 be changed via a pair of proxy change request/confirmation 300 messages. These association and proxy change messages must be 301 approved by the central coordinator (PANC in this document). 303 o LOADng is a reactive protocol operating at layer 2 or layer 3. 304 Currently, LOADng is supported in ITU-T G.9903 [ITU-T_G.9903], and 305 the IEEE 1901.2 standard refers to ITU-T G.9903 for LOAD-based 306 networks. 308 4. IPv6 over PLC 310 6LoWPAN and 6lo standards [RFC4944], [RFC6282], [RFC6775], and 311 [RFC8505] provides useful functionality including link-local IPv6 312 addresses, stateless address auto-configuration, neighbor discovery, 313 header compression, fragmentation and reassembly. However, due to 314 the different characteristics of the PLC media, the 6LoWPAN 315 adaptation layer, as it is, cannot perfectly fulfill the requirements 316 of PLC environments. These considerations suggest the need for a 317 dedicated adaptation layer for PLC, which is detailed in the 318 following subsections. 320 4.1. Stateless Address Autoconfiguration 322 To obtain an IPv6 Interface Identifier (IID), a PLC device performs 323 stateless address autoconfiguration [RFC4944]. The autoconfiguration 324 can be based on either a long or short link-layer address. 326 The IID can be based on the device's 48-bit MAC address or its EUI-64 327 identifier [EUI-64]. A 48-bit MAC address MUST first be extended to 328 a 64-bit Interface ID by inserting 0xFFFE at the fourth and fifth 329 octets as specified in [RFC2464]. The IPv6 IID is derived from the 330 64-bit Interface ID by inverting the U/L bit [RFC4291]. 332 For IEEE 1901.2 and ITU-T G.9903, a 48-bit "pseudo-address" is formed 333 by the 16-bit PAN ID, 16 zero bits and the 16-bit short address. 334 Then, the 64-bit Interface ID MUST be derived by inserting 16-bit 335 0xFFFE into as follows: 337 16_bit_PAN:00FF:FE00:16_bit_short_address 339 For the 12-bit short addresses used by IEEE 1901.1, the 48-bit 340 pseudo-address is formed by 24-bit NID (Network IDentifier, YYYYYY), 341 12 zero bits and a 12-bit TEI (Terminal Equipment Identifier, XXX). 342 The 64-bit Interface ID MUST be derived by inserting 16-bit 0xFFFE 343 into this 48-bit pseudo-address as follows: 345 YYYY:YYFF:FE00:0XXX 347 Since the derived Interface ID is not global, the "Universal/Local" 348 (U/L) bit (7th bit) and the Individual/Group bit (8th bit) MUST both 349 be set to zero. In order to avoid any ambiguity in the derived 350 Interface ID, these two bits MUST NOT be used to generate the PANID 351 (for IEEE 1901.2 and ITU-T G.9903) or NID (for IEEE 1901.1). In 352 other words, the PANID or NID MUST always be chosen so that these 353 bits are zeros. 355 For privacy reasons, the IID derived from the MAC address SHOULD only 356 be used for link-local address configuration. A PLC host SHOULD use 357 the IID derived from the link-layer short address to configure the 358 IPv6 address used for communication with the public network; 359 otherwise, the host's MAC address is exposed. As per [RFC8065], when 360 short addresses are used on PLC links, a shared secret key or version 361 number from the Authoritative Border Router Option [RFC6775] can be 362 used to improve the entropy of the hash input, thus the generated IID 363 can be spread out to the full range of the IID address space while 364 stateless address compression is still allowed. 366 4.2. IPv6 Link Local Address 368 The IPv6 link-local address [RFC4291] for a PLC interface is formed 369 by appending the IID, as defined above, to the prefix FE80::/64 (see 370 Figure 2). 372 10 bits 54 bits 64 bits 373 +----------+-----------------------+----------------------------+ 374 |1111111010| (zeros) | Interface Identifier | 375 +----------+-----------------------+----------------------------+ 377 Figure 2: IPv6 Link Local Address for a PLC interface 379 4.3. Unicast Address Mapping 381 The address resolution procedure for mapping IPv6 unicast addresses 382 into PLC link-layer addresses follows the general description in 383 section 7.2 of [RFC4861]. [RFC6775] improves this procedure by 384 eliminating usage of multicast NS. The resolution is realized by the 385 NCEs (neighbor cache entry) created during the address registration 386 at the routers. [RFC8505] further improves the registration 387 procedure by enabling multiple LLNs to form an IPv6 subnet, and by 388 inserting a link-local address registration to better serve proxy 389 registration of new devices. 391 4.3.1. Unicast Address Mapping for IEEE 1901.1 393 The Source/Target Link-layer Address options for IEEE_1901.1 used in 394 the Neighbor Solicitation and Neighbor Advertisement have the 395 following form. 397 0 1 2 3 398 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 399 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 400 | Type | Length=1 | NID : 401 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 402 :NID (continued)| Padding (all zeros) | TEI | 403 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 405 Figure 3: Unicast Address Mapping for IEEE 1901.1 407 Option fields: 409 Type: 1 for Source Link-layer Address and 2 for Target Link-layer 410 Address. 412 Length: The length of this option (including type and length fields) 413 in units of 8 octets. The value of this field is 1 for the 414 12-bit IEEE 1901.1 PLC short addresses. 416 NID: 24-bit Network IDentifier 418 Padding: 12 zero bits 420 TEI: 12-bit Terminal Equipment Identifier 422 In order to avoid the possibility of duplicated IPv6 addresses, the 423 value of the NID MUST be chosen so that the 7th and 8th bits of the 424 first byte of the NID are both zero. 426 4.3.2. Unicast Address Mapping for IEEE 1901.2 and ITU-T G.9903 428 The Source/Target Link-layer Address options for IEEE_1901.2 and 429 ITU-T G.9903 used in the Neighbor Solicitation and Neighbor 430 Advertisement have the following form. 432 0 1 2 3 433 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 434 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 435 | Type | Length=1 | PAN ID | 436 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 437 | Padding (all zeros) | Short Address | 438 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 440 Figure 4: Unicast Address Mapping for IEEE 1901.2 442 Option fields: 444 Type: 1 for Source Link-layer Address and 2 for Target Link-layer 445 Address. 447 Length: The length of this option (including type and length fields) 448 in units of 8 octets. The value of this field is 1 for the 449 16-bit IEEE 1901.2 PLC short addresses. 451 PAN ID: 16-bit PAN IDentifier 453 Padding: 16 zero bits 455 Short Address: 16-bit short address 457 In order to avoid the possibility of duplicated IPv6 addresses, the 458 value of the PAN ID MUST be chosen so that the 7th and 8th bits of 459 the first byte of the PAN ID are both zero. 461 4.4. Neighbor Discovery 463 Neighbor discovery procedures for 6LoWPAN networks are described in 464 Neighbor Discovery Optimization for 6LoWPANs [RFC6775] and [RFC8505]. 465 These optimizations support the registration of sleeping hosts. 466 Although PLC devices are electrically powered, sleeping mode SHOULD 467 still be used for power saving. 469 For IPv6 address prefix dissemination, Router Solicitations (RS) and 470 Router Advertisements (RA) MAY be used as per [RFC6775]. If the PLC 471 network uses route-over, the IPv6 prefix MAY be disseminated by the 472 layer 3 routing protocol, such as RPL, which may includes the prefix 473 in the DIO message. As per [I-D.ietf-roll-unaware-leaves], it is 474 possible to have PLC devices configured as RPL-unaware-leaves, which 475 do not participate to RPL at all, along with RPL-aware PLC devices. 476 In this case, the prefix dissemination SHOULD use the RS/RA messages. 478 For context information dissemination, Router Advertisements (RA) 479 MUST be used as per [RFC6775]. The 6LoWPAN context option (6CO) MUST 480 be included in the RA to disseminate the Context IDs used for prefix 481 and/or address compression. 483 For address registration in route-over mode, a PLC device MUST 484 register its addresses by sending unicast link-local Neighbor 485 Solicitation to the 6LR. If the registered address is link-local, 486 the 6LR SHOULD NOT further register it to the registrar (6LBR, 6BBR). 487 Otherwise, the address MUST be registered via an ARO or EARO included 488 in the DAR ([RFC6775]) or EDAR ([RFC8505]) messages. For RFC8505 489 compliant PLC devices, the 'R' flag in the EARO MUST be set when 490 sending Neighbor Solicitaitons in order to extract the status 491 information in the replied Neighbor Advertisements from the 6LR. If 492 DHCPv6 is used to assign addresses or the IPv6 address is derived 493 from unique long or short link layer address, Duplicate Address 494 Detection (DAD) MUST NOT be utilized. Otherwise, the DAD MUST be 495 performed at the 6LBR (as per [RFC6775]) or proxied by the routing 496 registrar (as per [RFC8505]). The registration status is feedbacked 497 via the DAC or EDAC message from the 6LBR and the Neighbor 498 Advertisement (NA) from the 6LR. 500 For address registration in mesh-under mode, since all the PLC 501 devices are link-local neighbors to the 6LBR, DAR/DAC or EDAR/EDAC 502 messages are not required. A PLC device MUST register its addresses 503 by sending a unicast NS message with an ARO or EARO. The 504 registration status is feedbacked via the NA message from the 6LBR. 506 4.5. Header Compression 508 The compression of IPv6 datagrams within PLC MAC frames refers to 509 [RFC6282], which updates [RFC4944]. Header compression as defined in 510 [RFC6282] which specifies the compression format for IPv6 datagrams 511 on top of IEEE 802.15.4, is the basis for IPv6 header compression in 512 PLC. For situations when PLC MAC MTU cannot support the 1280-octet 513 IPv6 packet, headers MUST be compressed according to [RFC6282] 514 encoding formats. 516 For IEEE 1901.2 and G.9903, the IP header compression follows the 517 instruction in [RFC6282]. However, additional adaptation MUST be 518 considered for IEEE 1901.1 since it has a short address of 12 bits 519 instead of 16 bits. The only modification is the semantics of the 520 "Source Address Mode" when set as "10" in the section 3.1 of 521 [RFC6282], which is illustrated as following. 523 SAM: Source Address Mode: 525 If SAC=0: Stateless compression 527 10: 12 bits. The first 116 bits of the address are elided.The 528 value of the first 64 bits is the link-local prefix padded with 529 zeros. The following 64 bits are 0000:00ff:fe00:0XXX, where 530 XXX are the 12 bits carried in-line. 532 If SAC=1: stateful context-based compression 534 10: 12 bits. The address is derived using context information and 535 the 12 bits carried in-line. Bits covered by context 536 information are always used. Any IID bits not covered by 537 context information are taken directly from their corresponding 538 bits in the 12-bit to IID mapping given by 0000:00ff:fe00:0XXX, 539 where XXX are the 12 bits carried inline. Any remaining bits 540 are zero. 542 4.6. Fragmentation and Reassembly 544 Constrained PLC MAC layer provides the function of fragmentation and 545 reassembly, however, fragmentation and reassembly is still required 546 at the adaptation layer, if the MAC layer cannot support the minimum 547 MTU demanded by IPv6, which is 1280 octets. 549 In IEEE 1901.1 and IEEE 1901.2, the MAC layer supports payloads as 550 big as 2031 octets and 1576 octets respectively. However when the 551 channel condition is noisy, it is possible to configure smaller MTU 552 at the MAC layer. If the configured MTU is smaller than 1280 553 octects, the fragmentation and reassembly defined in [RFC4944] MUST 554 be used. 556 In ITU-T G.9903, the maximum MAC payload size is fixed to 400 octets, 557 so to cope with the required MTU of 1280 octets by IPv6, 558 fragmentation and reassembly at 6lo adaptation layer MUST be provided 559 as specified in [RFC4944]. 561 [RFC4944] uses a 16-bit datagram tag to identify the fragments of the 562 same IP packet. [RFC4963] specifies that at high data rates, the 563 16-bit IP identification field is not large enough to prevent 564 frequent incorrectly assembled IP fragments. For constranied PLC, 565 the data rate is much lower than the situation mentioned in RFC4963, 566 thus the 16-bit tag is sufficient to assemble the fragements 567 correctly. 569 5. Internet Connectivity Scenarios and Topologies 571 The PLC network model can be simplified to two kinds of network 572 devices: PAN Coordinator (PANC) and PAN Device. The PANC is the 573 primary coordinator of the PLC subnet and can be seen as a master 574 node; PAN Devices are typically PLC meters and sensors. The PANC 575 also serves as the Routing Registrar for proxy registration and DAD 576 procedures, making use of the updated registration procedures in 577 [RFC8505]. IPv6 over PLC networks are built as tree, mesh or star 578 according to the use cases. Generally, each PLC network has one 579 PANC. In some cases, the PLC network can have alternate coordinators 580 to replace the PANC when the PANC leaves the network for some reason. 581 Note that the PLC topologies in this section are based on logical 582 connectivity, not physical links. The term "PLC subnet" refers to a 583 multilink subnet, in which the PLC devices share the same address 584 prefix. 586 The star topology is common in current PLC scenarios. In single-hop 587 star topologies, communication at the link layer only takes place 588 between a PAN Device and a PANC. The PANC typically collects data 589 (e.g., a meter reading) from the PAN devices, and then concentrates 590 and uploads the data through Ethernet or LPWAN (see Figure 5). The 591 collected data is transmitted by the smart meters through PLC, 592 aggregated by a concentrator, sent to the utility and then to a Meter 593 Data Management System for data storage, analysis and billing. This 594 topology has been widely applied in the deployment of smart meters, 595 especially in apartment buildings. 597 PLC Device PLC Device 598 \ / +--------- 599 \ / / 600 \ / + 601 \ / | 602 PLC Device ------ PANC ===========+ Internet 603 / \ | 604 / \ + 605 / \ \ 606 / \ +--------- 607 PLC Device PLC Device 609 <----------------------> 610 PLC subnet (IPv6 over PLC) 612 Figure 5: PLC Star Network connected to the Internet 614 A tree topology is useful when the distance between a device A and 615 PANC is beyond the PLC allowed limit and there is another device B in 616 between able to communicate with both sides. Device B in this case 617 acts both as a PAN Device and a Coordinator. For this scenario, the 618 link layer communications take place between device A and device B, 619 and between device B and PANC. An example of PLC tree network is 620 depicted in Figure 6. This topology can be applied in the smart 621 street lighting, where the lights adjust the brightness to reduce 622 energy consumption while sensors are deployed on the street lights to 623 provide information such as light intensity, temperature, humidity. 624 Data transmission distance in the street lighting scenario is 625 normally above several kilometers thus the PLC tree network is 626 required. A more sophisticated AMI network may also be constructed 627 into the tree topology which is depicted in [RFC8036]. A tree 628 topology is suitable for AMI scenarios that require large coverage 629 but low density, e.g., the deployment of smart meters in rural areas. 630 RPL is suitable for maintenance of a tree topology in which there is 631 no need for communication directly between PAN devices. 633 PLC Device 634 \ +--------- 635 PLC Device \ / 636 \ \ + 637 \ \ | 638 PLC Device -- PANC ===========+ Internet 639 / / | 640 / / + 641 PLC Device---PLC Device / \ 642 / +--------- 643 PLC Device---PLC Device 645 <-------------------------> 646 PLC subnet (IPv6 over PLC) 648 Figure 6: PLC Tree Network connected to the Internet 650 Mesh networking in PLC is of great potential applications and has 651 been studied for several years. By connecting all nodes with their 652 neighbors in communication range (see Figure 7), mesh topology 653 dramatically enhances the communication efficiency and thus expands 654 the size of PLC networks. A simple use case is the smart home 655 scenario where the ON/OFF state of air conditioning is controlled by 656 the state of home lights (ON/OFF) and doors (OPEN/CLOSE). AODV-RPL 657 enables direct PAN device to PAN device communication, without being 658 obliged to transmit frames through the PANC, which is a requirement 659 often cited for AMI infrastructure. 661 PLC Device---PLC Device 662 / \ / \ +--------- 663 / \ / \ / 664 / \ / \ + 665 / \ / \ | 666 PLC Device--PLC Device---PANC ===========+ Internet 667 \ / \ / | 668 \ / \ / + 669 \ / \ / \ 670 \ / \ / +--------- 671 PLC Device---PLC Device 673 <-------------------------------> 674 PLC subnet (IPv6 over PLC) 676 Figure 7: PLC Mesh Network connected to the Internet 678 6. Operations and Manageability Considerations 680 The constrained PLC networks are not managed in the same way as the 681 enterprise network or carrier network. The constrained PLC networks 682 as the other IoT networks, are designed to be self-organized and 683 self-managed. The software or firmware is flushed into the devices 684 before deployment by the vendor or operator. And during the 685 deployment process, the devices are bootstrapped, and no extra 686 configuration is needed to get the device connected to each other. 687 Once a device becomes offline, it goes back to the bootstrapping 688 stage and tries to rejoin the network. The onboard status of the 689 devices and the topology of the PLC network can be visualized via the 690 gateway. The recently-formed iotops WG in IETF is aming to design 691 more features for the management of IOT networks. 693 7. IANA Considerations 695 There are no IANA considerations related to this document. 697 8. Security Consideration 699 Due to the high accessibility of power grid, PLC might be susceptible 700 to eavesdropping within its communication coverage, e.g., one 701 apartment tenant may have the chance to monitor the other smart 702 meters in the same apartment building. Thus link layer security 703 mechanisms are designed in the PLC technologies mentioned in this 704 document. 706 Malicious PLC devices could paralyze the whole network via DOS 707 attacks, e.g., keep joining and leaving the network frequently, or 708 multicast routing messages containing fake metrics. A device may 709 also join a wrong or even malicious network, exposing its data to 710 illegal users. Mutual authentication of network and new device can 711 be conducted during the onboarding process of the new device. 712 Methods include protocols such as [RFC7925] (exchanging pre-installed 713 certificates over DTLS) , [I-D.ietf-6tisch-minimal-security] (which 714 uses pre-shared keys), and 715 [I-D.ietf-6tisch-dtsecurity-zerotouch-join] (which uses IDevID and 716 MASA service). It is also possible to use EAP methods such as 717 [I-D.ietf-emu-eap-noob] via transports like PANA [RFC5191]. No 718 specific mechanism is specified by this document as an appropriate 719 mechanism will depend upon deployment circumstances. 721 IP addresses may be used to track devices on the Internet; such 722 devices can in turn be linked to individuals and their activities. 723 Depending on the application and the actual use pattern, this may be 724 undesirable. To impede tracking, globally unique and non-changing 725 characteristics of IP addresses should be avoided, e.g., by 726 frequently changing the global prefix and avoiding unique link-layer 727 derived IIDs in addresses. [RFC8065] discusses the privacy threats 728 when interface identifiers (IID) are generated without sufficient 729 entropy, including correlation of activities over time, location 730 tracking, device-specific vulnerability exploitation, and address 731 scanning. Schemes such as limited lease period in DHCPv6 [RFC3315], 732 Cryptographically Generated Addresses (CGAs) [RFC3972], privacy 733 extensions [RFC4941], Hash-Based Addresses (HBAs) [RFC5535], or 734 semantically opaque addresses [RFC7217] SHOULD be considered to 735 enhance the IID privacy. 737 9. Acknowledgements 739 We gratefully acknowledge suggestions from the members of the IETF 740 6lo working group. Great thanks to Samita Chakrabarti and Gabriel 741 Montenegro for their feedback and support in connecting the IEEE and 742 ITU-T sides. Authors thank Scott Mansfield, Ralph Droms, Pat Kinney 743 for their guidance in the liaison process. Authors wish to thank 744 Stefano Galli, Thierry Lys, Yizhou Li, Yuefeng Wu and Michael 745 Richardson for their valuable comments and contributions. 747 10. References 749 10.1. Normative References 751 [IEEE_1901.1] 752 IEEE-SA Standards Board, "Standard for Medium Frequency 753 (less than 15 MHz) Power Line Communications for Smart 754 Grid Applications", IEEE 1901.1, May 2018, 755 . 757 [IEEE_1901.2] 758 IEEE-SA Standards Board, "IEEE Standard for Low-Frequency 759 (less than 500 kHz) Narrowband Power Line Communications 760 for Smart Grid Applications", IEEE 1901.2, October 2013, 761 . 764 [ITU-T_G.9903] 765 International Telecommunication Union, "Narrowband 766 orthogonal frequency division multiplexing power line 767 communication transceivers for G3-PLC networks", 768 ITU-T G.9903, February 2014, 769 . 771 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 772 Requirement Levels", BCP 14, RFC 2119, 773 DOI 10.17487/RFC2119, March 1997, 774 . 776 [RFC2464] Crawford, M., "Transmission of IPv6 Packets over Ethernet 777 Networks", RFC 2464, DOI 10.17487/RFC2464, December 1998, 778 . 780 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 781 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 782 DOI 10.17487/RFC4861, September 2007, 783 . 785 [RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler, 786 "Transmission of IPv6 Packets over IEEE 802.15.4 787 Networks", RFC 4944, DOI 10.17487/RFC4944, September 2007, 788 . 790 [RFC6282] Hui, J., Ed. and P. Thubert, "Compression Format for IPv6 791 Datagrams over IEEE 802.15.4-Based Networks", RFC 6282, 792 DOI 10.17487/RFC6282, September 2011, 793 . 795 [RFC6550] Winter, T., Ed., Thubert, P., Ed., Brandt, A., Hui, J., 796 Kelsey, R., Levis, P., Pister, K., Struik, R., Vasseur, 797 JP., and R. Alexander, "RPL: IPv6 Routing Protocol for 798 Low-Power and Lossy Networks", RFC 6550, 799 DOI 10.17487/RFC6550, March 2012, 800 . 802 [RFC6775] Shelby, Z., Ed., Chakrabarti, S., Nordmark, E., and C. 803 Bormann, "Neighbor Discovery Optimization for IPv6 over 804 Low-Power Wireless Personal Area Networks (6LoWPANs)", 805 RFC 6775, DOI 10.17487/RFC6775, November 2012, 806 . 808 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 809 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 810 May 2017, . 812 [RFC8505] Thubert, P., Ed., Nordmark, E., Chakrabarti, S., and C. 813 Perkins, "Registration Extensions for IPv6 over Low-Power 814 Wireless Personal Area Network (6LoWPAN) Neighbor 815 Discovery", RFC 8505, DOI 10.17487/RFC8505, November 2018, 816 . 818 10.2. Informative References 820 [EUI-64] IEEE-SA Standards Board, "Guidelines for 64-bit Global 821 Identifier (EUI-64) Registration Authority", IEEE EUI-64, 822 March 1997, . 825 [I-D.ietf-6tisch-dtsecurity-zerotouch-join] 826 Richardson, M., "6tisch Zero-Touch Secure Join protocol", 827 draft-ietf-6tisch-dtsecurity-zerotouch-join-04 (work in 828 progress), July 2019. 830 [I-D.ietf-6tisch-minimal-security] 831 Vucinic, M., Simon, J., Pister, K., and M. Richardson, 832 "Constrained Join Protocol (CoJP) for 6TiSCH", draft-ietf- 833 6tisch-minimal-security-15 (work in progress), December 834 2019. 836 [I-D.ietf-emu-eap-noob] 837 Aura, T., Sethi, M., and A. Peltonen, "Nimble out-of-band 838 authentication for EAP (EAP-NOOB)", draft-ietf-emu-eap- 839 noob-03 (work in progress), December 2020. 841 [I-D.ietf-roll-aodv-rpl] 842 Anamalamudi, S., Zhang, M., Perkins, C., Anand, S., and B. 843 Liu, "AODV based RPL Extensions for Supporting Asymmetric 844 P2P Links in Low-Power and Lossy Networks", draft-ietf- 845 roll-aodv-rpl-08 (work in progress), May 2020. 847 [I-D.ietf-roll-unaware-leaves] 848 Thubert, P. and M. Richardson, "Routing for RPL Leaves", 849 draft-ietf-roll-unaware-leaves-30 (work in progress), 850 January 2021. 852 [IEEE_1901.2a] 853 IEEE-SA Standards Board, "IEEE Standard for Low-Frequency 854 (less than 500 kHz) Narrowband Power Line Communications 855 for Smart Grid Applications - Amendment 1", IEEE 1901.2a, 856 September 2015, . 859 [RFC3315] Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins, 860 C., and M. Carney, "Dynamic Host Configuration Protocol 861 for IPv6 (DHCPv6)", RFC 3315, DOI 10.17487/RFC3315, July 862 2003, . 864 [RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)", 865 RFC 3972, DOI 10.17487/RFC3972, March 2005, 866 . 868 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 869 Architecture", RFC 4291, DOI 10.17487/RFC4291, February 870 2006, . 872 [RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy 873 Extensions for Stateless Address Autoconfiguration in 874 IPv6", RFC 4941, DOI 10.17487/RFC4941, September 2007, 875 . 877 [RFC4963] Heffner, J., Mathis, M., and B. Chandler, "IPv4 Reassembly 878 Errors at High Data Rates", RFC 4963, 879 DOI 10.17487/RFC4963, July 2007, 880 . 882 [RFC5191] Forsberg, D., Ohba, Y., Ed., Patil, B., Tschofenig, H., 883 and A. Yegin, "Protocol for Carrying Authentication for 884 Network Access (PANA)", RFC 5191, DOI 10.17487/RFC5191, 885 May 2008, . 887 [RFC5535] Bagnulo, M., "Hash-Based Addresses (HBA)", RFC 5535, 888 DOI 10.17487/RFC5535, June 2009, 889 . 891 [RFC7217] Gont, F., "A Method for Generating Semantically Opaque 892 Interface Identifiers with IPv6 Stateless Address 893 Autoconfiguration (SLAAC)", RFC 7217, 894 DOI 10.17487/RFC7217, April 2014, 895 . 897 [RFC7925] Tschofenig, H., Ed. and T. Fossati, "Transport Layer 898 Security (TLS) / Datagram Transport Layer Security (DTLS) 899 Profiles for the Internet of Things", RFC 7925, 900 DOI 10.17487/RFC7925, July 2016, 901 . 903 [RFC8036] Cam-Winget, N., Ed., Hui, J., and D. Popa, "Applicability 904 Statement for the Routing Protocol for Low-Power and Lossy 905 Networks (RPL) in Advanced Metering Infrastructure (AMI) 906 Networks", RFC 8036, DOI 10.17487/RFC8036, January 2017, 907 . 909 [RFC8065] Thaler, D., "Privacy Considerations for IPv6 Adaptation- 910 Layer Mechanisms", RFC 8065, DOI 10.17487/RFC8065, 911 February 2017, . 913 [SCENA] Cano, C., Pittolo, A., Malone, D., and L. Lampe, "State of 914 the Art in Power Line Communications: From the 915 Applications to the Medium", July 2016, 916 . 918 Authors' Addresses 920 Jianqiang Hou 921 Huawei Technologies 922 101 Software Avenue, 923 Nanjing 210012 924 China 926 Email: houjianqiang@huawei.com 928 Bing Liu 929 Huawei Technologies 930 No. 156 Beiqing Rd. Haidian District, 931 Beijing 100095 932 China 934 Email: remy.liubing@huawei.com 936 Yong-Geun Hong 937 Electronics and Telecommunications Research Institute 938 161 Gajeong-Dong Yuseung-Gu 939 Daejeon 305-700 940 Korea 942 Email: yghong@etri.re.kr 944 Xiaojun Tang 945 State Grid Electric Power Research Institute 946 19 Chengxin Avenue 947 Nanjing 211106 948 China 950 Email: itc@sgepri.sgcc.com.cn 952 Charles E. Perkins 953 Lupin Lodge 955 Email: charliep@computer.org