idnits 2.17.1 draft-ietf-6lo-plc-03.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 29, 2020) is 1458 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) == Missing Reference: 'EUI-64' is mentioned on line 325, but not defined == Outdated reference: A later version (-18) exists of draft-ietf-roll-aodv-rpl-07 == Outdated reference: A later version (-30) exists of draft-ietf-roll-unaware-leaves-15 -- 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 (~~), 5 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 31, 2020 Y-G. Hong 6 ETRI 7 X. Tang 8 SGEPRI 9 C. Perkins 10 April 29, 2020 12 Transmission of IPv6 Packets over PLC Networks 13 draft-ietf-6lo-plc-03 15 Abstract 17 Power Line Communication (PLC), namely using the electric-power lines 18 for indoor and outdoor communications, has been widely applied to 19 support Advanced Metering Infrastructure (AMI), especially smart 20 meters for electricity. The inherent advantage of existing 21 electricity infrastructure facilitates the expansion of PLC 22 deployments, and moreover, a wide variety of accessible devices 23 raises the potential demand of IPv6 for future applications. This 24 document describes how IPv6 packets are transported over constrained 25 PLC networks, such as ITU-T G.9903, IEEE 1901.1 and IEEE 1901.2. 27 Status of This Memo 29 This Internet-Draft is submitted in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF). Note that other groups may also distribute 34 working documents as Internet-Drafts. The list of current Internet- 35 Drafts is at https://datatracker.ietf.org/drafts/current/. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 This Internet-Draft will expire on October 31, 2020. 44 Copyright Notice 46 Copyright (c) 2020 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (https://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. Code Components extracted from this document must 55 include Simplified BSD License text as described in Section 4.e of 56 the Trust Legal Provisions and are provided without warranty as 57 described in the Simplified BSD License. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 62 2. Requirements Notation and Terminology . . . . . . . . . . . . 3 63 3. Overview of PLC . . . . . . . . . . . . . . . . . . . . . . . 5 64 3.1. Protocol Stack . . . . . . . . . . . . . . . . . . . . . 5 65 3.2. Addressing Modes . . . . . . . . . . . . . . . . . . . . 6 66 3.3. Maximum Transmission Unit . . . . . . . . . . . . . . . . 6 67 3.4. Routing Protocol . . . . . . . . . . . . . . . . . . . . 7 68 4. IPv6 over PLC . . . . . . . . . . . . . . . . . . . . . . . . 7 69 4.1. Stateless Address Autoconfiguration . . . . . . . . . . . 7 70 4.2. IPv6 Link Local Address . . . . . . . . . . . . . . . . . 8 71 4.3. Unicast Address Mapping . . . . . . . . . . . . . . . . . 9 72 4.3.1. Unicast Address Mapping for IEEE 1901.1 . . . . . . . 9 73 4.3.2. Unicast Address Mapping for IEEE 1901.2 and ITU-T 74 G.9903 . . . . . . . . . . . . . . . . . . . . . . . 10 75 4.4. Neighbor Discovery . . . . . . . . . . . . . . . . . . . 10 76 4.5. Header Compression . . . . . . . . . . . . . . . . . . . 11 77 4.6. Fragmentation and Reassembly . . . . . . . . . . . . . . 12 78 5. Internet Connectivity Scenarios and Topologies . . . . . . . 12 79 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 80 7. Security Consideration . . . . . . . . . . . . . . . . . . . 15 81 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 15 82 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 83 9.1. Normative References . . . . . . . . . . . . . . . . . . 16 84 9.2. Informative References . . . . . . . . . . . . . . . . . 17 85 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19 87 1. Introduction 89 The idea of using power lines for both electricity supply and 90 communication can be traced back to the beginning of the last 91 century. With the advantage of existing power grid, Power Line 92 Communication (PLC) is a good candidate for supporting various 93 service scenarios such as in houses and offices, in trains and 94 vehicles, in smart grid and advanced metering infrastructure (AMI). 95 The data acquisition devices in these scenarios share common features 96 such as fixed position, large quantity, low data rate and low power 97 consumption. 99 Although PLC technology has evolved over several decades, it has not 100 been fully adapted for IPv6 based constrained networks. The 6lo 101 related scenarios lie in the low voltage PLC networks with most 102 applications in the area of Advanced Metering Infrastructure (AMI), 103 Vehicle-to-Grid communications, in-home energy management and smart 104 street lighting. IPv6 is important for PLC networks, due to its 105 large address space and efficent address auto-configuration. A 106 comparison among various existing PLC standards is provided to 107 facilitate the selection of the most applicable standard in 108 particular scenarios. 110 This specification provides a brief overview of PLC technologies. 111 Some of them have LLN characteristics, i.e. limited power 112 consumption, memory and processing resources. This specification is 113 focused on the transmission of IPv6 packets over those "constrained" 114 PLC networks. The general approach is to adapt elements of the 115 6LoWPAN specifications [RFC4944], [RFC6282], and [RFC6775] to 116 constrained PLC networks. There was work previously proposed as 117 [I-D.popa-6lo-6loplc-ipv6-over-ieee19012-networks], which did not 118 reach consensus. This document provides a more structured 119 specification than the previous work, expanding to a larger variety 120 of PLC networks. 122 2. Requirements Notation and Terminology 124 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 125 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 126 "OPTIONAL" in this document are to be interpreted as described in 127 BCP14 [RFC2119] [RFC8174] when, and only when, they appear in all 128 capitals, as shown here. 130 This document often uses the following acronyms and terminologies: 132 6LoWPAN: IPv6 over Low-Power Wireless Personal Area Network 134 AMI: Advanced Metering Infrastructure 136 BBPLC: Broadband Power Line Communication 138 CID: Context ID 140 Coordinator: A device capable of relaying messages. 142 DAD: Duplicate Address Detection 143 EV: Electric Vehicle 145 IID: IPv6 Interface Identifier 147 IPHC: IP Header Compression 149 LAN: Local Area Network 151 MSDU: MAC Service Data Unit 153 MTU: Maximum Transmission Unit 155 NBPLC: Narrowband Power Line Communication 157 OFDM: Orthogonal Frequency Division Multiplexing 159 PANC: PAN Coordinator, a coordinator which also acts as the primary 160 controller of a PAN. 162 PLC: Power Line Communication 164 PLC device: An entity follows the PLC standards and implements the 165 protocol stack described in this draft. 167 PSDU: PHY Service Data Unit 169 RPL: IPv6 Routing Protocol for Low-Power and Lossy Networks 171 RA: Router Advertisement 173 WAN: Wide Area Network 175 The terminology used in this draft is aligned with IEEE 1901.2 177 +---------------+----------------+------------------+---------------+ 178 | IEEE 1901.2 | IEEE 1901.1 | ITU-T G.9903 | This document | 179 +---------------+----------------+------------------+---------------+ 180 | PAN | Central | PAN Coordinator | PAN | 181 | Coordinator | Coordinator | | Coordinator | 182 | | | | | 183 | Coordinator | Proxy | Full-function | Coordinator | 184 | | Coordinator | device | | 185 | | | | | 186 | Device | Station | PAN Device | PLC Device | 187 +---------------+----------------+------------------+---------------+ 189 Table 1: Terminology Mapping between PLC standards 191 3. Overview of PLC 193 PLC technology enables convenient two-way communications for home 194 users and utility companies to monitor and control electric plugged 195 devices such as electricity meters and street lights. Due to the 196 large range of communication frequencies, PLC is generally classified 197 into two categories: Narrowband PLC (NBPLC) for automation of sensors 198 (which have low frequency band and low power cost), and Broadband PLC 199 (BBPLC) for home and industry networking applications. 201 Various standards have been addressed on the MAC and PHY layers for 202 this communication technology, e.g., BBPLC (1.8-250 MHz) including 203 IEEE 1901 and ITU-T G.hn, and NBPLC (3-500 kHz) including ITU-T 204 G.9902 (G.hnem), ITU-T G.9903 (G3-PLC) [ITU-T_G.9903], ITU-T G.9904 205 (PRIME), IEEE 1901.2 [IEEE_1901.2] (combination of G3-PLC and PRIME 206 PLC) and IEEE 1901.2a [IEEE_1901.2a] (an amendment to IEEE 1901.2). 208 Moreover, recently a new PLC standard IEEE 1901.1 [IEEE_1901.1], 209 which aims at the medium frequency band less than 12 MHz, has been 210 published by the IEEE standard for Smart Grid Powerline Communication 211 Working Group (SGPLC WG). IEEE 1901.1 balances the needs for 212 bandwidth versus communication range, and is thus a promising option 213 for 6lo applications. 215 This specification is focused on IEEE 1901.1, IEEE 1901.2 and ITU-T 216 G.9903. 218 3.1. Protocol Stack 220 The protocol stack for IPv6 over PLC is illustrated in Figure 1. The 221 PLC MAC/PHY layer corresponds to IEEE 1901.1, IEEE 1901.2 or ITU-T 222 G.9903. The 6lo adaptation layer for PLC is illustrated in 223 Section 4. For multihop tree and mesh topologies, a routing protocol 224 is likely to be necessary. The routes can be built in mesh-under 225 mode at layer 2 or in route-over mode at layer 3, as explained in 226 Section 3.4. 228 +----------------------------------------+ 229 | Application Layer | 230 +----------------------------------------+ 231 | TCP/UDP | 232 +----------------------------------------+ 233 | | 234 | IPv6 | 235 | | 236 +----------------------------------------+ 237 | Adaptation layer for IPv6 over PLC | 238 +----------------------------------------+ 239 | PLC MAC Layer | 240 +----------------------------------------+ 241 | PLC PHY Layer | 242 +----------------------------------------+ 244 Figure 1: PLC Protocol Stack 246 3.2. Addressing Modes 248 Each PLC device has a globally unique long address of 48-bit 249 ([IEEE_1901.1]) or 64-bit ([IEEE_1901.2], [ITU-T_G.9903]) and a short 250 address of 12-bit ([IEEE_1901.1]) or 16-bit ([IEEE_1901.2], 251 [ITU-T_G.9903]). The long address is set by the manufacturer 252 according to the IEEE EUI-48 MAC address or the IEEE EUI-64 address. 253 Each PLC device joins the network by using the long address and 254 communicates with other devices by using the short address after 255 joining the network. Short addresses can be assigned during the 256 onboarding process, by the PANC or the JRC in CoJP 257 [I-D.ietf-6tisch-minimal-security]. 259 3.3. Maximum Transmission Unit 261 The Maximum Transmission Unit (MTU) of the MAC layer determines 262 whether fragmentation and reassembly are needed at the adaptation 263 layer of IPv6 over PLC. IPv6 requires an MTU of 1280 octets or 264 greater; thus for a MAC layer with MTU lower than this limit, 265 fragmentation and reassembly at the adaptation layer are required. 267 The IEEE 1901.1 MAC supports upper layer packets up to 2031 octets. 268 The IEEE 1901.2 MAC layer supports the MTU of 1576 octets (the 269 original value of 1280 bytes was updated in 2015 [IEEE_1901.2a]). 270 Though fragmentation and reassembly are not needed in these two 271 technologies, other 6lo functions like header compression are still 272 applicable and useful, particularly in high-noise communication 273 environments. 275 The MTU for ITU-T G.9903 is 400 octets, insufficient for supporting 276 IPv6's MTU. For this reason, fragmentation and reassembly as per 277 [RFC4944] MUST be enabled for G.9903-based networks. 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. For IPv6-addressable PLC networks, a 289 layer-3 routing protocol such as RPL and/or AODV-RPL SHOULD be 290 supported in the standard. 292 o IEEE 1901.1 supports L2 routing. Each PLC node maintains a L2 293 routing table, in which each route entry comprises the short 294 addresses of the destination and the related next hop. The route 295 entries are built during the network establishment via a pair of 296 association request/confirmation messages. The route entries can 297 be changed via a pair of proxy change request/confirmation 298 messages. These association and proxy change messages MUST be 299 approved by the central coordinator (PANC in this document). 301 o LOADng is a reactive protocol operating at layer 2 or layer 3. 302 Currently, LOADng is supported in ITU-T G.9903 [ITU-T_G.9903], and 303 the IEEE 1901.2 standard refers to ITU-T G.9903 for LOAD-based 304 networks. 306 4. IPv6 over PLC 308 6LoWPAN standards [RFC4944], [RFC6775], and [RFC6282] provides useful 309 functionality including link-local IPv6 addresses, stateless address 310 auto-configuration, neighbor discovery and header compression. 311 However, due to the different characteristics of the PLC media, the 312 6LoWPAN adaptation layer cannot perfectly fulfill the requirements. 313 Besides, some of the features like fragmentation and reassembly are 314 redudant to some PLC technologies. These considerations suggest the 315 need for a dedicated adaptation layer for PLC, which is detailed in 316 the following subsections. 318 4.1. Stateless Address Autoconfiguration 320 To obtain an IPv6 Interface Identifier (IID), a PLC device performs 321 stateless address autoconfiguration [RFC4944]. The autoconfiguration 322 can be based on either a long or short link-layer address. 324 The IID can be based on the device's 48-bit MAC address or its EUI-64 325 identifier [EUI-64]. A 48-bit MAC address MUST first be extended to 326 a 64-bit Interface ID by inserting 0xFFFE at the fourth and fifth 327 octets as specified in [RFC2464]. The IPv6 IID is derived from the 328 64-bit Interface ID by inverting the U/L bit [RFC4291]. 330 For IEEE 1901.2 and ITU-T G.9903, a 48-bit "pseudo-address" is formed 331 by the 16-bit PAN ID, 16 zero bits and the 16-bit short address. 332 Then, the 64-bit Interface ID MUST be derived by inserting 16-bit 333 0xFFFE into as follows: 335 16_bit_PAN:00FF:FE00:16_bit_short_address 337 For the 12-bit short addresses used by IEEE 1901.1, the 48-bit 338 pseudo-address is formed by 24-bit NID (Network IDentifier, YYYYYY), 339 12 zero bits and a 12-bit TEI (Terminal Equipment Identifier, XXX). 340 The 64-bit Interface ID MUST be derived by inserting 16-bit 0xFFFE 341 into this 48-bit pseudo-address as follows: 343 YYYY:YYFF:FE00:0XXX 345 Since the derived Interface ID is not global, the "Universal/Local" 346 (U/L) bit (7th bit) and the Individual/Group bit (8th bit) MUST both 347 be set to zero. In order to avoid any ambiguity in the derived 348 Interface ID, these two bits MUST NOT be used to generate the PANID 349 (for IEEE 1901.2 and ITU-T G.9903) or NID (for IEEE 1901.1). In 350 other words, the PANID or NID MUST always be chosen so that these 351 bits are zeros. 353 For privacy reasons, the IID derived by the MAC address SHOULD only 354 be used for link-local address configuration. A PLC host SHOULD use 355 the IID derived by the link-layer short address to configure the IPv6 356 address used for communication with the public network; otherwise, 357 the host's MAC address is exposed. 359 4.2. IPv6 Link Local Address 361 The IPv6 link-local address [RFC4291] for a PLC interface is formed 362 by appending the IID, as defined above, to the prefix FE80::/64 (see 363 Figure 2). Implementations should look at [RFC8064] as well, in 364 order to generate a stable IPv6 link-local address using an opaque 365 IID. 367 10 bits 54 bits 64 bits 368 +----------+-----------------------+----------------------------+ 369 |1111111010| (zeros) | Interface Identifier | 370 +----------+-----------------------+----------------------------+ 372 Figure 2: IPv6 Link Local Address for a PLC interface 374 4.3. Unicast Address Mapping 376 The address resolution procedure for mapping IPv6 unicast addresses 377 into PLC link-layer addresses follows the general description in 378 section 7.2 of [RFC4861]. [RFC6775] improves this procedure by 379 eliminating usage of multicast NS. The resolution is realized by the 380 NCEs (neighbor cache entry) created during the address registration 381 at the routers. [RFC8505] further improves the registration 382 procedure by enabling multiple LLNs to form an IPv6 subnet, and by 383 inserting a link-local address registration to better serve proxy 384 registration of new devices. 386 4.3.1. Unicast Address Mapping for IEEE 1901.1 388 The Source/Target Link-layer Address options for IEEE_1901.1 used in 389 the Neighbor Solicitation and Neighbor Advertisement have the 390 following form. 392 0 1 2 3 393 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 394 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 395 | Type | Length=1 | NID : 396 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 397 :NID (continued)| Padding (all zeros) | TEI | 398 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 400 Figure 3: Unicast Address Mapping for IEEE 1901.1 402 Option fields: 404 Type: 1 for Source Link-layer Address and 2 for Target Link-layer 405 Address. 407 Length: The length of this option (including type and length fields) 408 in units of 8 octets. The value of this field is 1 for the 409 12-bit IEEE 1901.1 PLC short addresses. 411 NID: 24-bit Network IDentifier 413 Padding: 12 zero bits 414 TEI: 12-bit Terminal Equipment Identifier 416 In order to avoid the possibility of duplicated IPv6 addresses, the 417 value of the NID MUST be chosen so that the 7th and 8th bits of the 418 first byte of the NID are both zero. 420 4.3.2. Unicast Address Mapping for IEEE 1901.2 and ITU-T G.9903 422 The Source/Target Link-layer Address options for IEEE_1901.2 and 423 ITU-T G.9903 used in the Neighbor Solicitation and Neighbor 424 Advertisement have the following form. 426 0 1 2 3 427 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 428 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 429 | Type | Length=1 | PAN ID | 430 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 431 | Padding (all zeros) | Short Address | 432 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 434 Figure 4: Unicast Address Mapping for IEEE 1901.2 436 Option fields: 438 Type: 1 for Source Link-layer Address and 2 for Target Link-layer 439 Address. 441 Length: The length of this option (including type and length fields) 442 in units of 8 octets. The value of this field is 1 for the 443 16-bit IEEE 1901.2 PLC short addresses. 445 PAN ID: 16-bit PAN IDentifier 447 Padding: 16 zero bits 449 Short Address: 16-bit short address 451 In order to avoid the possibility of duplicated IPv6 addresses, the 452 value of the PAN ID MUST be chosen so that the 7th and 8th bits of 453 the first byte of the PAN ID are both zero. 455 4.4. Neighbor Discovery 457 Neighbor discovery procedures for 6LoWPAN networks are described in 458 Neighbor Discovery Optimization for 6LoWPANs [RFC6775] and [RFC8505]. 459 These optimizations support the registration of sleeping hosts. 460 Although PLC devices are electrically powered, sleeping mode SHOULD 461 still be used for power saving. 463 For IPv6 address prefix dissemination, Router Solicitations (RS) and 464 Router Advertisements (RA) MAY be used as per [RFC6775]. If the PLC 465 network uses route-over mesh, the IPv6 prefix MAY be disseminated by 466 the layer 3 routing protocol, such as RPL which includes the prefix 467 in the DIO message. As per [I-D.ietf-roll-unaware-leaves], it is 468 possible to have PLC devices configured as RPL-unaware-leaves, which 469 don't not participate to RPL at all, along with RPL-aware PLC 470 devices. In this case, the prefix dissemination SHOULD use the RS/RA 471 messages. 473 For context information dissemination, Router Advertisements (RA) 474 MUST be used as per [RFC6775]. The 6LoWPAN context option (6CO) MUST 475 be included in the RA to disseminate the Context IDs used for prefix 476 compression. 478 For address registration in route-over mode, a PLC device MUST 479 register its addresses by sending unicast link-local Neighbor 480 Solicitation to the 6LR. If the registered address is link-local, 481 the 6LR SHOULD NOT further register it to the registrar (6LBR, 6BBR). 482 Otherwise, the address MUST be registered via an ARO or EARO included 483 in the DAR ([RFC6775]) or EDAR ([RFC8505]) messages. For RFC8505 484 compliant PLC devices, the 'R' flag in the EARO MUST be set when 485 sending Neighbor Solicitaitons in order to extract the status 486 information in the replied Neighbor Advertisements from the 6LR. If 487 DHCPv6 is used to assign addresses or the IPv6 address is derived by 488 unique long or short link layer address, Duplicate Address Detection 489 (DAD) MUST NOT be utilized. Otherwise, the DAD MUST be performed at 490 the 6LBR (as per [RFC6775]) or proxied by the routing registrar (as 491 per [RFC8505]). The registration status is feedbacked via the DAC or 492 EDAC message from the 6LBR and the Neighbor Advertisement (NA) from 493 the 6LR. 495 For address registration in mesh-under mode, since all the PLC 496 devices are the link-local neighbors to the 6LBR, DAR/DAC or EDAR/ 497 EDAC messages are not required. A PLC device MUST register its 498 addresses by sending the unicast NS message with an ARO or EARO. The 499 registration status is feedbacked via the NA message from the 6LBR. 501 4.5. Header Compression 503 The compression of IPv6 datagrams within PLC MAC frames refers to 504 [RFC6282], which updates [RFC4944]. Header compression as defined in 505 [RFC6282] which specifies the compression format for IPv6 datagrams 506 on top of IEEE 802.15.4, is included in this document as the basis 507 for IPv6 header compression in PLC. For situations when PLC MAC MTU 508 cannot support the 1280-octet IPv6 packet, headers MUST be compressed 509 according to [RFC6282] encoding formats. 511 4.6. Fragmentation and Reassembly 513 PLC differs from other wired technologies in that the communication 514 medium is not shielded; thus, to successfully transmit data through 515 power lines, PLC Data Link layer provides the function of 516 segmentation and reassembly. A Segment Control Field is defined in 517 the MAC frame header regardless of whether segmentation is required. 518 The number of data octets of the PHY payload can change dynamically 519 based on channel conditions, thus the MAC payload segmentation in the 520 MAC sublayer is enabled and guarantees a reliable one-hop data 521 transmission. Fragmentation and reassembly is still required at the 522 adaptation layer, if the MAC layer cannot support the minimum MTU 523 demanded by IPv6, which is 1280 octets. 525 In IEEE 1901.1 and IEEE 1901.2, since the MAC layer supports payloads 526 of 2031 octets and 1576 octets respectively, fragmentation is not 527 needed for IPv6 packet transmission. The fragmentation and 528 reassembly defined in [RFC4944] SHOULD NOT be used in the 6lo 529 adaptation layer of IEEE 1901.2. 531 In ITU-T G.9903, the maximum MAC payload size is fixed to 400 octets, 532 so to cope with the required MTU of 1280 octets by IPv6, 533 fragmentation and reassembly at 6lo adaptation layer MUST be provided 534 referring to [RFC4944]. 536 5. Internet Connectivity Scenarios and Topologies 538 The network model can be simplified to two kinds of network devices: 539 PAN Coordinator (PANC) and PAN Device. The PANC is the primary 540 coordinator of the PLC subnet and can be seen as a master node; PAN 541 Devices are typically PLC meters and sensors. The PANC also serves 542 as the Routing Registrar for proxy registration and DAD procedures, 543 making use of the updated registration procedures in [RFC8505]. IPv6 544 over PLC networks are built as tree, mesh or star according to the 545 use cases. Every network requires at least one PANC to communicate 546 with each PAN Device. Note that the PLC topologies in this section 547 are based on logical connectivity, not physical links. 549 The star topology is common in current PLC scenarios. In single-hop 550 star topologies, communication at the link layer only takes place 551 between a PAN Device and a PANC. The PANC typically collects data 552 (e.g., a meter reading) from the PAN devices, and then concentrates 553 and uploads the data through Ethernet or LPWAN (see Figure 5). The 554 collected data is transmitted by the smart meters through PLC, 555 aggregated by a concentrator, sent to the utility and then to a Meter 556 Data Management System for data storage, analysis and billing. This 557 topology has been widely applied in the deployment of smart meters, 558 especially in apartment buildings. 560 PLC Device PLC Device 561 \ / +--------- 562 \ / / 563 \ / + 564 \ / | 565 PLC Device ------ PANC ===========+ Internet 566 / \ | 567 / \ + 568 / \ \ 569 / \ +--------- 570 PLC Device PLC Device 572 <----------------------> 573 PLC subnet (IPv6 over PLC) 575 Figure 5: PLC Star Network connected to the Internet 577 A tree topology is useful when the distance between a device A and 578 PANC is beyond the PLC allowed limit and there is another device B in 579 between able to communicate with both sides. Device B in this case 580 acts both as a PAN Device and a Coordinator. For this scenario, the 581 link layer communications take place between device A and device B, 582 and between device B and PANC. An example of PLC tree network is 583 depicted in Figure 6. This topology can be applied in the smart 584 street lighting, where the lights adjust the brightness to reduce 585 energy consumption while sensors are deployed on the street lights to 586 provide information such as light intensity, temperature, humidity. 587 Data transmission distance in the street lighting scenario is 588 normally above several kilometers thus the PLC tree network is 589 required. A more sophisticated AMI network may also be constructed 590 into the tree topology which is depicted in [RFC8036]. A tree 591 topology is suitable for AMI scenarios that require large coverage 592 but low density, e.g., the deployment of smart meters in rural areas. 593 RPL is suitable for maintenance of a tree topology in which there is 594 no need for communication directly between PAN devices. 596 PLC Device 597 \ +--------- 598 PLC Device \ / 599 \ \ + 600 \ \ | 601 PLC Device -- PANC ===========+ Internet 602 / / | 603 / / + 604 PLC Device---PLC Device / \ 605 / +--------- 606 PAN Device---PAN Device 608 <-------------------------> 609 PLC subnet (IPv6 over PLC) 611 Figure 6: PLC Tree Network connected to the Internet 613 Mesh networking in PLC is of great potential applications and has 614 been studied for several years. By connecting all nodes with their 615 neighbors in communication range (see Figure 7), mesh topology 616 dramatically enhances the communication efficiency and thus expands 617 the size of PLC networks. A simple use case is the smart home 618 scenario where the ON/OFF state of air conditioning is controlled by 619 the state of home lights (ON/OFF) and doors (OPEN/CLOSE). AODV-RPL 620 enables direct PAN device to PAN device communication, without being 621 obliged to transmit frames through the PANC, which is a requirement 622 often cited for AMI infrastructure. 624 PLC Device---PLC Device 625 / \ / \ +--------- 626 / \ / \ / 627 / \ / \ + 628 / \ / \ | 629 PLC Device--PLC Device---PANC ===========+ Internet 630 \ / \ / | 631 \ / \ / + 632 \ / \ / \ 633 \ / \ / +--------- 634 PLC Device---PLC Device 636 <-------------------------------> 637 PLC subnet (IPv6 over PLC) 639 Figure 7: PLC Mesh Network connected to the Internet 641 6. IANA Considerations 643 There are no IANA considerations related to this document. 645 7. Security Consideration 647 Due to the high accessibility of power grid, PLC might be susceptible 648 to eavesdropping within its communication coverage, e.g., one 649 apartment tenant may have the chance to monitor the other smart 650 meters in the same apartment building. For security consideration, 651 link layer security is guaranteed in every PLC technology. 653 Malicious PLC devices could paralyze the whole network via DOS 654 attacks, e.g., keep joining and leaving the network frequently, or 655 multicast routing messages containing fake metrics. A device may 656 also join a wrong or even malicious network, exposing its data to 657 illegal users. Thus it is highly recommended to conduct a mutual 658 authentication between the network and the device tending to join in 659 it. Pre-installed certificates can be transported over DTLS to 660 facilitate the authentication. Alternatively, as per 661 [I-D.ietf-6tisch-minimal-security], provisioning a unique pre-shared 662 keys (PSKs) to each PLC device is also feasible. In both cases, if 663 the PLC device is not direct neighbor to the PANC/JRC, where the 664 authenticate is conducted, another PLC device which has joined the 665 network can act as a proxy to help exchange the authentication 666 messages. 668 IP addresses may be used to track devices on the Internet; such 669 devices can in turn be linked to individuals and their activities. 670 Depending on the application and the actual use pattern, this may be 671 undesirable. To impede tracking, globally unique and non-changing 672 characteristics of IP addresses should be avoided, e.g., by 673 frequently changing the global prefix and avoiding unique link-layer 674 derived IIDs in addresses. [RFC3315], [RFC3972], [RFC4941], 675 [RFC5535], [RFC7217], and [RFC8065] provide valuable information for 676 IID formation with improved privacy, and are RECOMMENDED for IPv6 677 networks. 679 8. Acknowledgements 681 We gratefully acknowledge suggestions from the members of the IETF 682 6lo working group. Great thanks to Samita Chakrabarti and Gabriel 683 Montenegro for their feedback and support in connecting the IEEE and 684 ITU-T sides. Authors thank Scott Mansfield, Ralph Droms, Pat Kinney 685 for their guidance in the liaison process. Authors wish to thank 686 Stefano Galli, Thierry Lys, Yizhou Li and Yuefeng Wu for their 687 valuable comments and contributions. 689 9. References 691 9.1. Normative References 693 [IEEE_1901.1] 694 IEEE-SA Standards Board, "Standard for Medium Frequency 695 (less than 15 MHz) Power Line Communications for Smart 696 Grid Applications", IEEE 1901.1, May 2018, 697 . 699 [IEEE_1901.2] 700 IEEE-SA Standards Board, "IEEE Standard for Low-Frequency 701 (less than 500 kHz) Narrowband Power Line Communications 702 for Smart Grid Applications", IEEE 1901.2, October 2013, 703 . 706 [ITU-T_G.9903] 707 International Telecommunication Union, "Narrowband 708 orthogonal frequency division multiplexing power line 709 communication transceivers for G3-PLC networks", 710 ITU-T G.9903, February 2014, 711 . 713 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 714 Requirement Levels", BCP 14, RFC 2119, 715 DOI 10.17487/RFC2119, March 1997, 716 . 718 [RFC2464] Crawford, M., "Transmission of IPv6 Packets over Ethernet 719 Networks", RFC 2464, DOI 10.17487/RFC2464, December 1998, 720 . 722 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 723 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 724 DOI 10.17487/RFC4861, September 2007, 725 . 727 [RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler, 728 "Transmission of IPv6 Packets over IEEE 802.15.4 729 Networks", RFC 4944, DOI 10.17487/RFC4944, September 2007, 730 . 732 [RFC6282] Hui, J., Ed. and P. Thubert, "Compression Format for IPv6 733 Datagrams over IEEE 802.15.4-Based Networks", RFC 6282, 734 DOI 10.17487/RFC6282, September 2011, 735 . 737 [RFC6550] Winter, T., Ed., Thubert, P., Ed., Brandt, A., Hui, J., 738 Kelsey, R., Levis, P., Pister, K., Struik, R., Vasseur, 739 JP., and R. Alexander, "RPL: IPv6 Routing Protocol for 740 Low-Power and Lossy Networks", RFC 6550, 741 DOI 10.17487/RFC6550, March 2012, 742 . 744 [RFC6775] Shelby, Z., Ed., Chakrabarti, S., Nordmark, E., and C. 745 Bormann, "Neighbor Discovery Optimization for IPv6 over 746 Low-Power Wireless Personal Area Networks (6LoWPANs)", 747 RFC 6775, DOI 10.17487/RFC6775, November 2012, 748 . 750 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 751 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 752 May 2017, . 754 [RFC8505] Thubert, P., Ed., Nordmark, E., Chakrabarti, S., and C. 755 Perkins, "Registration Extensions for IPv6 over Low-Power 756 Wireless Personal Area Network (6LoWPAN) Neighbor 757 Discovery", RFC 8505, DOI 10.17487/RFC8505, November 2018, 758 . 760 9.2. Informative References 762 [I-D.ietf-6tisch-minimal-security] 763 Vucinic, M., Simon, J., Pister, K., and M. Richardson, 764 "Constrained Join Protocol (CoJP) for 6TiSCH", draft-ietf- 765 6tisch-minimal-security-15 (work in progress), December 766 2019. 768 [I-D.ietf-roll-aodv-rpl] 769 Anamalamudi, S., Zhang, M., Perkins, C., Anand, S., and B. 770 Liu, "Asymmetric AODV-P2P-RPL in Low-Power and Lossy 771 Networks (LLNs)", draft-ietf-roll-aodv-rpl-07 (work in 772 progress), April 2019. 774 [I-D.ietf-roll-unaware-leaves] 775 Thubert, P. and M. Richardson, "Routing for RPL Leaves", 776 draft-ietf-roll-unaware-leaves-15 (work in progress), 777 April 2020. 779 [I-D.popa-6lo-6loplc-ipv6-over-ieee19012-networks] 780 Popa, D. and J. Hui, "6LoPLC: Transmission of IPv6 Packets 781 over IEEE 1901.2 Narrowband Powerline Communication 782 Networks", draft-popa-6lo-6loplc-ipv6-over- 783 ieee19012-networks-00 (work in progress), March 2014. 785 [IEEE_1901.2a] 786 IEEE-SA Standards Board, "IEEE Standard for Low-Frequency 787 (less than 500 kHz) Narrowband Power Line Communications 788 for Smart Grid Applications - Amendment 1", IEEE 1901.2a, 789 September 2015, . 792 [RFC3315] Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins, 793 C., and M. Carney, "Dynamic Host Configuration Protocol 794 for IPv6 (DHCPv6)", RFC 3315, DOI 10.17487/RFC3315, July 795 2003, . 797 [RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)", 798 RFC 3972, DOI 10.17487/RFC3972, March 2005, 799 . 801 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 802 Architecture", RFC 4291, DOI 10.17487/RFC4291, February 803 2006, . 805 [RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy 806 Extensions for Stateless Address Autoconfiguration in 807 IPv6", RFC 4941, DOI 10.17487/RFC4941, September 2007, 808 . 810 [RFC5535] Bagnulo, M., "Hash-Based Addresses (HBA)", RFC 5535, 811 DOI 10.17487/RFC5535, June 2009, 812 . 814 [RFC7217] Gont, F., "A Method for Generating Semantically Opaque 815 Interface Identifiers with IPv6 Stateless Address 816 Autoconfiguration (SLAAC)", RFC 7217, 817 DOI 10.17487/RFC7217, April 2014, 818 . 820 [RFC8036] Cam-Winget, N., Ed., Hui, J., and D. Popa, "Applicability 821 Statement for the Routing Protocol for Low-Power and Lossy 822 Networks (RPL) in Advanced Metering Infrastructure (AMI) 823 Networks", RFC 8036, DOI 10.17487/RFC8036, January 2017, 824 . 826 [RFC8064] Gont, F., Cooper, A., Thaler, D., and W. Liu, 827 "Recommendation on Stable IPv6 Interface Identifiers", 828 RFC 8064, DOI 10.17487/RFC8064, February 2017, 829 . 831 [RFC8065] Thaler, D., "Privacy Considerations for IPv6 Adaptation- 832 Layer Mechanisms", RFC 8065, DOI 10.17487/RFC8065, 833 February 2017, . 835 Authors' Addresses 837 Jianqiang Hou 838 Huawei Technologies 839 101 Software Avenue, 840 Nanjing 210012 841 China 843 Email: houjianqiang@huawei.com 845 Bing Liu 846 Huawei Technologies 847 No. 156 Beiqing Rd. Haidian District, 848 Beijing 100095 849 China 851 Email: remy.liubing@huawei.com 853 Yong-Geun Hong 854 Electronics and Telecommunications Research Institute 855 161 Gajeong-Dong Yuseung-Gu 856 Daejeon 305-700 857 Korea 859 Email: yghong@etri.re.kr 861 Xiaojun Tang 862 State Grid Electric Power Research Institute 863 19 Chengxin Avenue 864 Nanjing 211106 865 China 867 Email: itc@sgepri.sgcc.com.cn 869 Charles E. Perkins 871 Email: charliep@computer.org