idnits 2.17.00 (12 Aug 2021) /tmp/idnits60542/draft-ietf-6lo-plc-04.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 (June 3, 2020) is 717 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 324, but not defined == 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 (~~), 7 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: December 5, 2020 Y-G. Hong 6 ETRI 7 X. Tang 8 SGEPRI 9 C. Perkins 10 June 3, 2020 12 Transmission of IPv6 Packets over PLC Networks 13 draft-ietf-6lo-plc-04 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 December 5, 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 these two technologies can support IPv6 natively without 271 fragmentation and reassembly, it is possible to configure a smaller 272 MTU in high-noise communication environment. Thus the 6lo functions, 273 including header compression, fragmentation and reassembly, are still 274 applicable and useful. 276 The MTU for ITU-T G.9903 is 400 octets, insufficient for supporting 277 IPv6's MTU. For this reason, fragmentation and reassembly as per 278 [RFC4944] MUST be enabled for G.9903-based networks. 280 3.4. Routing Protocol 282 Routing protocols suitable for use in PLC networks include: 284 o RPL (Routing Protocol for Low-Power and Lossy Networks) [RFC6550] 285 is a layer 3 routing protocol. AODV-RPL [I-D.ietf-roll-aodv-rpl] 286 updates RPL to include reactive, point-to-point, and asymmetric 287 routing. IEEE 1901.2 specifies Information Elements (IEs) with 288 MAC layer metrics, which can be provided to L3 routing protocol 289 for parent selection. For IPv6-addressable PLC networks, a 290 layer-3 routing protocol such as RPL and/or AODV-RPL SHOULD be 291 supported in the standard. 293 o IEEE 1901.1 supports L2 routing. Each PLC node maintains a L2 294 routing table, in which each route entry comprises the short 295 addresses of the destination and the related next hop. The route 296 entries are built during the network establishment via a pair of 297 association request/confirmation messages. The route entries can 298 be changed via a pair of proxy change request/confirmation 299 messages. These association and proxy change messages MUST be 300 approved by the central coordinator (PANC in this document). 302 o LOADng is a reactive protocol operating at layer 2 or layer 3. 303 Currently, LOADng is supported in ITU-T G.9903 [ITU-T_G.9903], and 304 the IEEE 1901.2 standard refers to ITU-T G.9903 for LOAD-based 305 networks. 307 4. IPv6 over PLC 309 6LoWPAN standards [RFC4944], [RFC6775], and [RFC6282] provides useful 310 functionality including link-local IPv6 addresses, stateless address 311 auto-configuration, neighbor discovery and header compression. 312 However, due to the different characteristics of the PLC media, the 313 6LoWPAN adaptation layer cannot perfectly fulfill the requirements. 314 These considerations suggest the need for a dedicated adaptation 315 layer for PLC, which is detailed in the 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. 331 Then, the 64-bit Interface ID MUST be derived by inserting 16-bit 332 0xFFFE into as follows: 334 16_bit_PAN:00FF:FE00:16_bit_short_address 336 For the 12-bit short addresses used by IEEE 1901.1, the 48-bit 337 pseudo-address is formed by 24-bit NID (Network IDentifier, YYYYYY), 338 12 zero bits and a 12-bit TEI (Terminal Equipment Identifier, XXX). 339 The 64-bit Interface ID MUST be derived by inserting 16-bit 0xFFFE 340 into this 48-bit pseudo-address as follows: 342 YYYY:YYFF:FE00:0XXX 344 Since the derived Interface ID is not global, the "Universal/Local" 345 (U/L) bit (7th bit) and the Individual/Group bit (8th bit) MUST both 346 be set to zero. In order to avoid any ambiguity in the derived 347 Interface ID, these two bits MUST NOT be used to generate the PANID 348 (for IEEE 1901.2 and ITU-T G.9903) or NID (for IEEE 1901.1). In 349 other words, the PANID or NID MUST always be chosen so that these 350 bits are zeros. 352 For privacy reasons, the IID derived by the MAC address SHOULD only 353 be used for link-local address configuration. A PLC host SHOULD use 354 the IID derived by the link-layer short address to configure the IPv6 355 address used for communication with the public network; otherwise, 356 the host's MAC address is exposed. Implementations should look at 357 [RFC8064] as well, in order to generate a stable IPv6 address using 358 an opaque IID. 360 4.2. IPv6 Link Local Address 362 The IPv6 link-local address [RFC4291] for a PLC interface is formed 363 by appending the IID, as defined above, to the prefix FE80::/64 (see 364 Figure 2). 366 10 bits 54 bits 64 bits 367 +----------+-----------------------+----------------------------+ 368 |1111111010| (zeros) | Interface Identifier | 369 +----------+-----------------------+----------------------------+ 371 Figure 2: IPv6 Link Local Address for a PLC interface 373 4.3. Unicast Address Mapping 375 The address resolution procedure for mapping IPv6 unicast addresses 376 into PLC link-layer addresses follows the general description in 377 section 7.2 of [RFC4861]. [RFC6775] improves this procedure by 378 eliminating usage of multicast NS. The resolution is realized by the 379 NCEs (neighbor cache entry) created during the address registration 380 at the routers. [RFC8505] further improves the registration 381 procedure by enabling multiple LLNs to form an IPv6 subnet, and by 382 inserting a link-local address registration to better serve proxy 383 registration of new devices. 385 4.3.1. Unicast Address Mapping for IEEE 1901.1 387 The Source/Target Link-layer Address options for IEEE_1901.1 used in 388 the Neighbor Solicitation and Neighbor Advertisement have the 389 following form. 391 0 1 2 3 392 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 393 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 394 | Type | Length=1 | NID : 395 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 396 :NID (continued)| Padding (all zeros) | TEI | 397 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 399 Figure 3: Unicast Address Mapping for IEEE 1901.1 401 Option fields: 403 Type: 1 for Source Link-layer Address and 2 for Target Link-layer 404 Address. 406 Length: The length of this option (including type and length fields) 407 in units of 8 octets. The value of this field is 1 for the 408 12-bit IEEE 1901.1 PLC short addresses. 410 NID: 24-bit Network IDentifier 412 Padding: 12 zero bits 413 TEI: 12-bit Terminal Equipment Identifier 415 In order to avoid the possibility of duplicated IPv6 addresses, the 416 value of the NID MUST be chosen so that the 7th and 8th bits of the 417 first byte of the NID are both zero. 419 4.3.2. Unicast Address Mapping for IEEE 1901.2 and ITU-T G.9903 421 The Source/Target Link-layer Address options for IEEE_1901.2 and 422 ITU-T G.9903 used in the Neighbor Solicitation and Neighbor 423 Advertisement have the following form. 425 0 1 2 3 426 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 427 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 428 | Type | Length=1 | PAN ID | 429 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 430 | Padding (all zeros) | Short Address | 431 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 433 Figure 4: Unicast Address Mapping for IEEE 1901.2 435 Option fields: 437 Type: 1 for Source Link-layer Address and 2 for Target Link-layer 438 Address. 440 Length: The length of this option (including type and length fields) 441 in units of 8 octets. The value of this field is 1 for the 442 16-bit IEEE 1901.2 PLC short addresses. 444 PAN ID: 16-bit PAN IDentifier 446 Padding: 16 zero bits 448 Short Address: 16-bit short address 450 In order to avoid the possibility of duplicated IPv6 addresses, the 451 value of the PAN ID MUST be chosen so that the 7th and 8th bits of 452 the first byte of the PAN ID are both zero. 454 4.4. Neighbor Discovery 456 Neighbor discovery procedures for 6LoWPAN networks are described in 457 Neighbor Discovery Optimization for 6LoWPANs [RFC6775] and [RFC8505]. 458 These optimizations support the registration of sleeping hosts. 459 Although PLC devices are electrically powered, sleeping mode SHOULD 460 still be used for power saving. 462 For IPv6 address prefix dissemination, Router Solicitations (RS) and 463 Router Advertisements (RA) MAY be used as per [RFC6775]. If the PLC 464 network uses route-over mesh, the IPv6 prefix MAY be disseminated by 465 the layer 3 routing protocol, such as RPL which includes the prefix 466 in the DIO message. As per [I-D.ietf-roll-unaware-leaves], it is 467 possible to have PLC devices configured as RPL-unaware-leaves, which 468 don't not participate to RPL at all, along with RPL-aware PLC 469 devices. In this case, the prefix dissemination SHOULD use the RS/RA 470 messages. 472 For context information dissemination, Router Advertisements (RA) 473 MUST be used as per [RFC6775]. The 6LoWPAN context option (6CO) MUST 474 be included in the RA to disseminate the Context IDs used for prefix 475 compression. 477 For address registration in route-over mode, a PLC device MUST 478 register its addresses by sending unicast link-local Neighbor 479 Solicitation to the 6LR. If the registered address is link-local, 480 the 6LR SHOULD NOT further register it to the registrar (6LBR, 6BBR). 481 Otherwise, the address MUST be registered via an ARO or EARO included 482 in the DAR ([RFC6775]) or EDAR ([RFC8505]) messages. For RFC8505 483 compliant PLC devices, the 'R' flag in the EARO MUST be set when 484 sending Neighbor Solicitaitons in order to extract the status 485 information in the replied Neighbor Advertisements from the 6LR. If 486 DHCPv6 is used to assign addresses or the IPv6 address is derived by 487 unique long or short link layer address, Duplicate Address Detection 488 (DAD) MUST NOT be utilized. Otherwise, the DAD MUST be performed at 489 the 6LBR (as per [RFC6775]) or proxied by the routing registrar (as 490 per [RFC8505]). The registration status is feedbacked via the DAC or 491 EDAC message from the 6LBR and the Neighbor Advertisement (NA) from 492 the 6LR. 494 For address registration in mesh-under mode, since all the PLC 495 devices are the link-local neighbors to the 6LBR, DAR/DAC or EDAR/ 496 EDAC messages are not required. A PLC device MUST register its 497 addresses by sending the unicast NS message with an ARO or EARO. The 498 registration status is feedbacked via the NA message from the 6LBR. 500 4.5. Header Compression 502 The compression of IPv6 datagrams within PLC MAC frames refers to 503 [RFC6282], which updates [RFC4944]. Header compression as defined in 504 [RFC6282] which specifies the compression format for IPv6 datagrams 505 on top of IEEE 802.15.4, is included in this document as the basis 506 for IPv6 header compression in PLC. For situations when PLC MAC MTU 507 cannot support the 1280-octet IPv6 packet, headers MUST be compressed 508 according to [RFC6282] encoding formats. 510 4.6. Fragmentation and Reassembly 512 PLC differs from other wired technologies in that the communication 513 medium is not shielded; thus, to successfully transmit data through 514 power lines, PLC Data Link layer provides the function of 515 segmentation and reassembly. A Segment Control Field is defined in 516 the MAC frame header regardless of whether segmentation is required. 517 The number of data octets of the PHY payload can change dynamically 518 based on channel conditions, thus the MAC payload segmentation in the 519 MAC sublayer is enabled and guarantees a reliable one-hop data 520 transmission. Fragmentation and reassembly is still required at the 521 adaptation layer, if the MAC layer cannot support the minimum MTU 522 demanded by IPv6, which is 1280 octets. 524 In IEEE 1901.1 and IEEE 1901.2, the MAC layer supports payloads as 525 big as 2031 octets and 1576 octets respectively. However when the 526 channel condition is noisy, it is possible to configure smaller MTU 527 at the MAC layer. If the configured MTU is smaller than 1280 528 octects, the fragmentation and reassembly defined in [RFC4944] MUST 529 be used. 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 PLC Device---PLC 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. Mutual authentication of network and new device can 658 be conducted during the onboarding process of the new device. 659 Methods include protocols such as [RFC7925] (exchanging pre-installed 660 certificates over DTLS) , [I-D.ietf-6tisch-minimal-security] (which 661 uses pre-shared keys), and 662 [I-D.ietf-6tisch-dtsecurity-zerotouch-join] (which uses IDevID and 663 MASA service). It is also possible to use EAP methods such as 664 [I-D.ietf-emu-eap-noob] via transports like PANA [RFC5191]. No 665 specific mechanism is specified by this document as an appropriate 666 mechanism will depend upon deployment circumstances. The network 667 encryption key appropriate for the layer-2 can also be acquired 668 during the onboarding process. 670 IP addresses may be used to track devices on the Internet; such 671 devices can in turn be linked to individuals and their activities. 672 Depending on the application and the actual use pattern, this may be 673 undesirable. To impede tracking, globally unique and non-changing 674 characteristics of IP addresses should be avoided, e.g., by 675 frequently changing the global prefix and avoiding unique link-layer 676 derived IIDs in addresses. [RFC3315], [RFC3972], [RFC4941], 677 [RFC5535], [RFC7217], and [RFC8065] provide valuable information for 678 IID formation with improved privacy, and are RECOMMENDED for IPv6 679 networks. 681 8. Acknowledgements 683 We gratefully acknowledge suggestions from the members of the IETF 684 6lo working group. Great thanks to Samita Chakrabarti and Gabriel 685 Montenegro for their feedback and support in connecting the IEEE and 686 ITU-T sides. Authors thank Scott Mansfield, Ralph Droms, Pat Kinney 687 for their guidance in the liaison process. Authors wish to thank 688 Stefano Galli, Thierry Lys, Yizhou Li, Yuefeng Wu and Michael 689 Richardson for their valuable comments and contributions. 691 9. References 693 9.1. Normative References 695 [IEEE_1901.1] 696 IEEE-SA Standards Board, "Standard for Medium Frequency 697 (less than 15 MHz) Power Line Communications for Smart 698 Grid Applications", IEEE 1901.1, May 2018, 699 . 701 [IEEE_1901.2] 702 IEEE-SA Standards Board, "IEEE Standard for Low-Frequency 703 (less than 500 kHz) Narrowband Power Line Communications 704 for Smart Grid Applications", IEEE 1901.2, October 2013, 705 . 708 [ITU-T_G.9903] 709 International Telecommunication Union, "Narrowband 710 orthogonal frequency division multiplexing power line 711 communication transceivers for G3-PLC networks", 712 ITU-T G.9903, February 2014, 713 . 715 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 716 Requirement Levels", BCP 14, RFC 2119, 717 DOI 10.17487/RFC2119, March 1997, 718 . 720 [RFC2464] Crawford, M., "Transmission of IPv6 Packets over Ethernet 721 Networks", RFC 2464, DOI 10.17487/RFC2464, December 1998, 722 . 724 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 725 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 726 DOI 10.17487/RFC4861, September 2007, 727 . 729 [RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler, 730 "Transmission of IPv6 Packets over IEEE 802.15.4 731 Networks", RFC 4944, DOI 10.17487/RFC4944, September 2007, 732 . 734 [RFC6282] Hui, J., Ed. and P. Thubert, "Compression Format for IPv6 735 Datagrams over IEEE 802.15.4-Based Networks", RFC 6282, 736 DOI 10.17487/RFC6282, September 2011, 737 . 739 [RFC6550] Winter, T., Ed., Thubert, P., Ed., Brandt, A., Hui, J., 740 Kelsey, R., Levis, P., Pister, K., Struik, R., Vasseur, 741 JP., and R. Alexander, "RPL: IPv6 Routing Protocol for 742 Low-Power and Lossy Networks", RFC 6550, 743 DOI 10.17487/RFC6550, March 2012, 744 . 746 [RFC6775] Shelby, Z., Ed., Chakrabarti, S., Nordmark, E., and C. 747 Bormann, "Neighbor Discovery Optimization for IPv6 over 748 Low-Power Wireless Personal Area Networks (6LoWPANs)", 749 RFC 6775, DOI 10.17487/RFC6775, November 2012, 750 . 752 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 753 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 754 May 2017, . 756 [RFC8505] Thubert, P., Ed., Nordmark, E., Chakrabarti, S., and C. 757 Perkins, "Registration Extensions for IPv6 over Low-Power 758 Wireless Personal Area Network (6LoWPAN) Neighbor 759 Discovery", RFC 8505, DOI 10.17487/RFC8505, November 2018, 760 . 762 9.2. Informative References 764 [I-D.ietf-6tisch-dtsecurity-zerotouch-join] 765 Richardson, M., "6tisch Zero-Touch Secure Join protocol", 766 draft-ietf-6tisch-dtsecurity-zerotouch-join-04 (work in 767 progress), July 2019. 769 [I-D.ietf-6tisch-minimal-security] 770 Vucinic, M., Simon, J., Pister, K., and M. Richardson, 771 "Constrained Join Protocol (CoJP) for 6TiSCH", draft-ietf- 772 6tisch-minimal-security-15 (work in progress), December 773 2019. 775 [I-D.ietf-emu-eap-noob] 776 Aura, T. and M. Sethi, "Nimble out-of-band authentication 777 for EAP (EAP-NOOB)", draft-ietf-emu-eap-noob-01 (work in 778 progress), June 2020. 780 [I-D.ietf-roll-aodv-rpl] 781 Anamalamudi, S., Zhang, M., Perkins, C., Anand, S., and B. 782 Liu, "AODV based RPL Extensions for Supporting Asymmetric 783 P2P Links in Low-Power and Lossy Networks", draft-ietf- 784 roll-aodv-rpl-08 (work in progress), May 2020. 786 [I-D.ietf-roll-unaware-leaves] 787 Thubert, P. and M. Richardson, "Routing for RPL Leaves", 788 draft-ietf-roll-unaware-leaves-15 (work in progress), 789 April 2020. 791 [I-D.popa-6lo-6loplc-ipv6-over-ieee19012-networks] 792 Popa, D. and J. Hui, "6LoPLC: Transmission of IPv6 Packets 793 over IEEE 1901.2 Narrowband Powerline Communication 794 Networks", draft-popa-6lo-6loplc-ipv6-over- 795 ieee19012-networks-00 (work in progress), March 2014. 797 [IEEE_1901.2a] 798 IEEE-SA Standards Board, "IEEE Standard for Low-Frequency 799 (less than 500 kHz) Narrowband Power Line Communications 800 for Smart Grid Applications - Amendment 1", IEEE 1901.2a, 801 September 2015, . 804 [RFC3315] Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins, 805 C., and M. Carney, "Dynamic Host Configuration Protocol 806 for IPv6 (DHCPv6)", RFC 3315, DOI 10.17487/RFC3315, July 807 2003, . 809 [RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)", 810 RFC 3972, DOI 10.17487/RFC3972, March 2005, 811 . 813 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 814 Architecture", RFC 4291, DOI 10.17487/RFC4291, February 815 2006, . 817 [RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy 818 Extensions for Stateless Address Autoconfiguration in 819 IPv6", RFC 4941, DOI 10.17487/RFC4941, September 2007, 820 . 822 [RFC5191] Forsberg, D., Ohba, Y., Ed., Patil, B., Tschofenig, H., 823 and A. Yegin, "Protocol for Carrying Authentication for 824 Network Access (PANA)", RFC 5191, DOI 10.17487/RFC5191, 825 May 2008, . 827 [RFC5535] Bagnulo, M., "Hash-Based Addresses (HBA)", RFC 5535, 828 DOI 10.17487/RFC5535, June 2009, 829 . 831 [RFC7217] Gont, F., "A Method for Generating Semantically Opaque 832 Interface Identifiers with IPv6 Stateless Address 833 Autoconfiguration (SLAAC)", RFC 7217, 834 DOI 10.17487/RFC7217, April 2014, 835 . 837 [RFC7925] Tschofenig, H., Ed. and T. Fossati, "Transport Layer 838 Security (TLS) / Datagram Transport Layer Security (DTLS) 839 Profiles for the Internet of Things", RFC 7925, 840 DOI 10.17487/RFC7925, July 2016, 841 . 843 [RFC8036] Cam-Winget, N., Ed., Hui, J., and D. Popa, "Applicability 844 Statement for the Routing Protocol for Low-Power and Lossy 845 Networks (RPL) in Advanced Metering Infrastructure (AMI) 846 Networks", RFC 8036, DOI 10.17487/RFC8036, January 2017, 847 . 849 [RFC8064] Gont, F., Cooper, A., Thaler, D., and W. Liu, 850 "Recommendation on Stable IPv6 Interface Identifiers", 851 RFC 8064, DOI 10.17487/RFC8064, February 2017, 852 . 854 [RFC8065] Thaler, D., "Privacy Considerations for IPv6 Adaptation- 855 Layer Mechanisms", RFC 8065, DOI 10.17487/RFC8065, 856 February 2017, . 858 Authors' Addresses 860 Jianqiang Hou 861 Huawei Technologies 862 101 Software Avenue, 863 Nanjing 210012 864 China 866 Email: houjianqiang@huawei.com 867 Bing Liu 868 Huawei Technologies 869 No. 156 Beiqing Rd. Haidian District, 870 Beijing 100095 871 China 873 Email: remy.liubing@huawei.com 875 Yong-Geun Hong 876 Electronics and Telecommunications Research Institute 877 161 Gajeong-Dong Yuseung-Gu 878 Daejeon 305-700 879 Korea 881 Email: yghong@etri.re.kr 883 Xiaojun Tang 884 State Grid Electric Power Research Institute 885 19 Chengxin Avenue 886 Nanjing 211106 887 China 889 Email: itc@sgepri.sgcc.com.cn 891 Charles E. Perkins 893 Email: charliep@computer.org