idnits 2.17.1 draft-ietf-6lo-plc-05.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 (October 28, 2020) is 1269 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-06) exists of draft-ietf-emu-eap-noob-02 == Outdated reference: A later version (-18) exists of draft-ietf-roll-aodv-rpl-08 == Outdated reference: A later version (-30) exists of draft-ietf-roll-unaware-leaves-22 -- 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: May 1, 2021 Y-G. Hong 6 ETRI 7 X. Tang 8 SGEPRI 9 C. Perkins 10 October 28, 2020 12 Transmission of IPv6 Packets over PLC Networks 13 draft-ietf-6lo-plc-05 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 May 1, 2021. 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 . . . . . . . 13 79 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 80 7. Security Consideration . . . . . . . . . . . . . . . . . . . 16 81 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 16 82 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 83 9.1. Normative References . . . . . . . . . . . . . . . . . . 17 84 9.2. Informative References . . . . . . . . . . . . . . . . . 18 85 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20 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], [RFC6775] and [RFC8505] 116 to 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 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 that follows the PLC standards and implements 165 the 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 of 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 (join registrar/ 257 coordinator) in CoJP (Constrained Join Protocol) 258 [I-D.ietf-6tisch-minimal-security]. 260 3.3. Maximum Transmission Unit 262 The Maximum Transmission Unit (MTU) of the MAC layer determines 263 whether fragmentation and reassembly are needed at the adaptation 264 layer of IPv6 over PLC. IPv6 requires an MTU of 1280 octets or 265 greater; thus for a MAC layer with MTU lower than this limit, 266 fragmentation and reassembly at the adaptation layer are required. 268 The IEEE 1901.1 MAC supports upper layer packets up to 2031 octets. 269 The IEEE 1901.2 MAC layer supports the MTU of 1576 octets (the 270 original value of 1280 bytes was updated in 2015 [IEEE_1901.2a]). 271 Though these two technologies can support IPv6 natively without 272 fragmentation and reassembly, it is possible to configure a smaller 273 MTU in high-noise communication environment. Thus the 6lo functions, 274 including header compression, fragmentation and reassembly, are still 275 applicable and useful. 277 The MTU for ITU-T G.9903 is 400 octets, insufficient for supporting 278 IPv6's MTU. For this reason, fragmentation and reassembly as per 279 [RFC4944] MUST be enabled for G.9903-based networks. 281 3.4. Routing Protocol 283 Routing protocols suitable for use in PLC networks include: 285 o RPL (Routing Protocol for Low-Power and Lossy Networks) [RFC6550] 286 is a layer 3 routing protocol. AODV-RPL [I-D.ietf-roll-aodv-rpl] 287 updates RPL to include reactive, point-to-point, and asymmetric 288 routing. IEEE 1901.2 specifies Information Elements (IEs) with 289 MAC layer metrics, which can be provided to L3 routing protocol 290 for parent selection. 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 and 6lo standards [RFC4944], [RFC6282], [RFC6775], and 309 [RFC8505] provides useful functionality including link-local IPv6 310 addresses, stateless address auto-configuration, neighbor discovery, 311 header compression, fragmentation and reassembly. However, due to 312 the different characteristics of the PLC media, the 6LoWPAN 313 adaptation layer, as it is, cannot perfectly fulfill the requirements 314 of PLC environments. These considerations suggest the need for a 315 dedicated adaptation layer for PLC, which is detailed in the 316 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 from the MAC address SHOULD only 354 be used for link-local address configuration. A PLC host SHOULD use 355 the IID derived from the link-layer short address to configure the 356 IPv6 address used for communication with the public network; 357 otherwise, the host's MAC address is exposed. Implementers should 358 look at [RFC8064] as well, in order to generate a stable IPv6 address 359 using an opaque IID. 361 4.2. IPv6 Link Local Address 363 The IPv6 link-local address [RFC4291] for a PLC interface is formed 364 by appending the IID, as defined above, to the prefix FE80::/64 (see 365 Figure 2). 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, the IPv6 prefix MAY be disseminated by the 466 layer 3 routing protocol, such as RPL, which may 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 do not participate to RPL at all, along with RPL-aware PLC devices. 470 In this case, the prefix dissemination SHOULD use the RS/RA 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 and/or address 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 487 from unique long or short link layer address, Duplicate Address 488 Detection (DAD) MUST NOT be utilized. Otherwise, the DAD MUST be 489 performed at the 6LBR (as per [RFC6775]) or proxied by the routing 490 registrar (as per [RFC8505]). The registration status is feedbacked 491 via the DAC or EDAC message from the 6LBR and the Neighbor 492 Advertisement (NA) from the 6LR. 494 For address registration in mesh-under mode, since all the PLC 495 devices are link-local neighbors to the 6LBR, DAR/DAC or EDAR/EDAC 496 messages are not required. A PLC device MUST register its addresses 497 by sending a 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 the basis for IPv6 header compression in 506 PLC. For situations when PLC MAC MTU cannot support the 1280-octet 507 IPv6 packet, headers MUST be compressed according to [RFC6282] 508 encoding formats. 510 For IEEE 1901.2 and G.9903, the IP header compression follows the 511 instruction in [RFC6282]. However, additional adaptation MUST be 512 considered for IEEE 1901.1 since it has a short address of 12 bits 513 instead of 16 bits. The only modification is the semantics of the 514 "Source Address Mode" when set as "10" in the section 3.1 of 515 [RFC6282], which is illustrated as following. 517 SAM: Source Address Mode: 519 If SAC=0: Stateless compression 521 10: 12 bits. The first 116 bits of the address are elided.The 522 value of the first 64 bits is the link-local prefix padded with 523 zeros. The following 64 bits are 0000:00ff:fe00:0XXX, where 524 XXX are the 12 bits carried in-line. 526 If SAC=1: stateful context-based compression 528 10: 12 bits. The address is derived using context information and 529 the 12 bits carried in-line. Bits covered by context 530 information are always used. Any IID bits not covered by 531 context information are taken directly from their corresponding 532 bits in the 12-bit to IID mapping given by 0000:00ff:fe00:0XXX, 533 where XXX are the 12 bits carried inline. Any remaining bits 534 are zero. 536 4.6. Fragmentation and Reassembly 538 PLC differs from other wired technologies in that the communication 539 medium is not shielded; thus, to successfully transmit data through 540 power lines, PLC Data Link layer provides the function of 541 segmentation and reassembly. A Segment Control Field is defined in 542 the MAC frame header regardless of whether segmentation is required. 543 The number of data octets of the PHY payload can change dynamically 544 based on channel conditions, thus the MAC payload segmentation in the 545 MAC sublayer is enabled and guarantees a reliable one-hop data 546 transmission. Fragmentation and reassembly is still required at the 547 adaptation layer, if the MAC layer cannot support the minimum MTU 548 demanded by IPv6, which is 1280 octets. 550 In IEEE 1901.1 and IEEE 1901.2, the MAC layer supports payloads as 551 big as 2031 octets and 1576 octets respectively. However when the 552 channel condition is noisy, it is possible to configure smaller MTU 553 at the MAC layer. If the configured MTU is smaller than 1280 554 octects, the fragmentation and reassembly defined in [RFC4944] MUST 555 be used. 557 In ITU-T G.9903, the maximum MAC payload size is fixed to 400 octets, 558 so to cope with the required MTU of 1280 octets by IPv6, 559 fragmentation and reassembly at 6lo adaptation layer MUST be provided 560 referring to [RFC4944]. 562 5. Internet Connectivity Scenarios and Topologies 564 The PLC network model can be simplified to two kinds of network 565 devices: PAN Coordinator (PANC) and PAN Device. The PANC is the 566 primary coordinator of the PLC subnet and can be seen as a master 567 node; PAN Devices are typically PLC meters and sensors. The PANC 568 also serves as the Routing Registrar for proxy registration and DAD 569 procedures, making use of the updated registration procedures in 570 [RFC8505]. IPv6 over PLC networks are built as tree, mesh or star 571 according to the use cases. Generally, each PLC network has one 572 PANC. In some cases, the PLC network can have alternate coordinators 573 to replace the PANC when the PANC leaves the network for some reason. 574 Note that the PLC topologies in this section are based on logical 575 connectivity, not physical links. The term "PLC subnet" refers to a 576 multilink subnet, in which the PLC devices share the same address 577 prefix. 579 The star topology is common in current PLC scenarios. In single-hop 580 star topologies, communication at the link layer only takes place 581 between a PAN Device and a PANC. The PANC typically collects data 582 (e.g., a meter reading) from the PAN devices, and then concentrates 583 and uploads the data through Ethernet or LPWAN (see Figure 5). The 584 collected data is transmitted by the smart meters through PLC, 585 aggregated by a concentrator, sent to the utility and then to a Meter 586 Data Management System for data storage, analysis and billing. This 587 topology has been widely applied in the deployment of smart meters, 588 especially in apartment buildings. 590 PLC Device PLC Device 591 \ / +--------- 592 \ / / 593 \ / + 594 \ / | 595 PLC Device ------ PANC ===========+ Internet 596 / \ | 597 / \ + 598 / \ \ 599 / \ +--------- 600 PLC Device PLC Device 602 <----------------------> 603 PLC subnet (IPv6 over PLC) 605 Figure 5: PLC Star Network connected to the Internet 607 A tree topology is useful when the distance between a device A and 608 PANC is beyond the PLC allowed limit and there is another device B in 609 between able to communicate with both sides. Device B in this case 610 acts both as a PAN Device and a Coordinator. For this scenario, the 611 link layer communications take place between device A and device B, 612 and between device B and PANC. An example of PLC tree network is 613 depicted in Figure 6. This topology can be applied in the smart 614 street lighting, where the lights adjust the brightness to reduce 615 energy consumption while sensors are deployed on the street lights to 616 provide information such as light intensity, temperature, humidity. 617 Data transmission distance in the street lighting scenario is 618 normally above several kilometers thus the PLC tree network is 619 required. A more sophisticated AMI network may also be constructed 620 into the tree topology which is depicted in [RFC8036]. A tree 621 topology is suitable for AMI scenarios that require large coverage 622 but low density, e.g., the deployment of smart meters in rural areas. 623 RPL is suitable for maintenance of a tree topology in which there is 624 no need for communication directly between PAN devices. 626 PLC Device 627 \ +--------- 628 PLC Device \ / 629 \ \ + 630 \ \ | 631 PLC Device -- PANC ===========+ Internet 632 / / | 633 / / + 634 PLC Device---PLC Device / \ 635 / +--------- 636 PLC Device---PLC Device 638 <-------------------------> 639 PLC subnet (IPv6 over PLC) 641 Figure 6: PLC Tree Network connected to the Internet 643 Mesh networking in PLC is of great potential applications and has 644 been studied for several years. By connecting all nodes with their 645 neighbors in communication range (see Figure 7), mesh topology 646 dramatically enhances the communication efficiency and thus expands 647 the size of PLC networks. A simple use case is the smart home 648 scenario where the ON/OFF state of air conditioning is controlled by 649 the state of home lights (ON/OFF) and doors (OPEN/CLOSE). AODV-RPL 650 enables direct PAN device to PAN device communication, without being 651 obliged to transmit frames through the PANC, which is a requirement 652 often cited for AMI infrastructure. 654 PLC Device---PLC Device 655 / \ / \ +--------- 656 / \ / \ / 657 / \ / \ + 658 / \ / \ | 659 PLC Device--PLC Device---PANC ===========+ Internet 660 \ / \ / | 661 \ / \ / + 662 \ / \ / \ 663 \ / \ / +--------- 664 PLC Device---PLC Device 666 <-------------------------------> 667 PLC subnet (IPv6 over PLC) 669 Figure 7: PLC Mesh Network connected to the Internet 671 6. IANA Considerations 673 There are no IANA considerations related to this document. 675 7. Security Consideration 677 Due to the high accessibility of power grid, PLC might be susceptible 678 to eavesdropping within its communication coverage, e.g., one 679 apartment tenant may have the chance to monitor the other smart 680 meters in the same apartment building. For security consideration, 681 link layer security is guaranteed in every PLC technology. 683 Malicious PLC devices could paralyze the whole network via DOS 684 attacks, e.g., keep joining and leaving the network frequently, or 685 multicast routing messages containing fake metrics. A device may 686 also join a wrong or even malicious network, exposing its data to 687 illegal users. Mutual authentication of network and new device can 688 be conducted during the onboarding process of the new device. 689 Methods include protocols such as [RFC7925] (exchanging pre-installed 690 certificates over DTLS) , [I-D.ietf-6tisch-minimal-security] (which 691 uses pre-shared keys), and 692 [I-D.ietf-6tisch-dtsecurity-zerotouch-join] (which uses IDevID and 693 MASA service). It is also possible to use EAP methods such as 694 [I-D.ietf-emu-eap-noob] via transports like PANA [RFC5191]. No 695 specific mechanism is specified by this document as an appropriate 696 mechanism will depend upon deployment circumstances. The network 697 encryption key appropriate for the layer-2 can also be acquired 698 during the onboarding process. 700 IP addresses may be used to track devices on the Internet; such 701 devices can in turn be linked to individuals and their activities. 702 Depending on the application and the actual use pattern, this may be 703 undesirable. To impede tracking, globally unique and non-changing 704 characteristics of IP addresses should be avoided, e.g., by 705 frequently changing the global prefix and avoiding unique link-layer 706 derived IIDs in addresses. [RFC3315], [RFC3972], [RFC4941], 707 [RFC5535], [RFC7217], and [RFC8065] provide valuable information for 708 IID formation with improved privacy, and are RECOMMENDED for IPv6 709 networks. 711 8. Acknowledgements 713 We gratefully acknowledge suggestions from the members of the IETF 714 6lo working group. Great thanks to Samita Chakrabarti and Gabriel 715 Montenegro for their feedback and support in connecting the IEEE and 716 ITU-T sides. Authors thank Scott Mansfield, Ralph Droms, Pat Kinney 717 for their guidance in the liaison process. Authors wish to thank 718 Stefano Galli, Thierry Lys, Yizhou Li, Yuefeng Wu and Michael 719 Richardson for their valuable comments and contributions. 721 9. References 723 9.1. Normative References 725 [IEEE_1901.1] 726 IEEE-SA Standards Board, "Standard for Medium Frequency 727 (less than 15 MHz) Power Line Communications for Smart 728 Grid Applications", IEEE 1901.1, May 2018, 729 . 731 [IEEE_1901.2] 732 IEEE-SA Standards Board, "IEEE Standard for Low-Frequency 733 (less than 500 kHz) Narrowband Power Line Communications 734 for Smart Grid Applications", IEEE 1901.2, October 2013, 735 . 738 [ITU-T_G.9903] 739 International Telecommunication Union, "Narrowband 740 orthogonal frequency division multiplexing power line 741 communication transceivers for G3-PLC networks", 742 ITU-T G.9903, February 2014, 743 . 745 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 746 Requirement Levels", BCP 14, RFC 2119, 747 DOI 10.17487/RFC2119, March 1997, 748 . 750 [RFC2464] Crawford, M., "Transmission of IPv6 Packets over Ethernet 751 Networks", RFC 2464, DOI 10.17487/RFC2464, December 1998, 752 . 754 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 755 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 756 DOI 10.17487/RFC4861, September 2007, 757 . 759 [RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler, 760 "Transmission of IPv6 Packets over IEEE 802.15.4 761 Networks", RFC 4944, DOI 10.17487/RFC4944, September 2007, 762 . 764 [RFC6282] Hui, J., Ed. and P. Thubert, "Compression Format for IPv6 765 Datagrams over IEEE 802.15.4-Based Networks", RFC 6282, 766 DOI 10.17487/RFC6282, September 2011, 767 . 769 [RFC6550] Winter, T., Ed., Thubert, P., Ed., Brandt, A., Hui, J., 770 Kelsey, R., Levis, P., Pister, K., Struik, R., Vasseur, 771 JP., and R. Alexander, "RPL: IPv6 Routing Protocol for 772 Low-Power and Lossy Networks", RFC 6550, 773 DOI 10.17487/RFC6550, March 2012, 774 . 776 [RFC6775] Shelby, Z., Ed., Chakrabarti, S., Nordmark, E., and C. 777 Bormann, "Neighbor Discovery Optimization for IPv6 over 778 Low-Power Wireless Personal Area Networks (6LoWPANs)", 779 RFC 6775, DOI 10.17487/RFC6775, November 2012, 780 . 782 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 783 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 784 May 2017, . 786 [RFC8505] Thubert, P., Ed., Nordmark, E., Chakrabarti, S., and C. 787 Perkins, "Registration Extensions for IPv6 over Low-Power 788 Wireless Personal Area Network (6LoWPAN) Neighbor 789 Discovery", RFC 8505, DOI 10.17487/RFC8505, November 2018, 790 . 792 9.2. Informative References 794 [EUI-64] IEEE-SA Standards Board, "Guidelines for 64-bit Global 795 Identifier (EUI-64) Registration Authority", IEEE EUI-64, 796 March 1997, . 799 [I-D.ietf-6tisch-dtsecurity-zerotouch-join] 800 Richardson, M., "6tisch Zero-Touch Secure Join protocol", 801 draft-ietf-6tisch-dtsecurity-zerotouch-join-04 (work in 802 progress), July 2019. 804 [I-D.ietf-6tisch-minimal-security] 805 Vucinic, M., Simon, J., Pister, K., and M. Richardson, 806 "Constrained Join Protocol (CoJP) for 6TiSCH", draft-ietf- 807 6tisch-minimal-security-15 (work in progress), December 808 2019. 810 [I-D.ietf-emu-eap-noob] 811 Aura, T. and M. Sethi, "Nimble out-of-band authentication 812 for EAP (EAP-NOOB)", draft-ietf-emu-eap-noob-02 (work in 813 progress), July 2020. 815 [I-D.ietf-roll-aodv-rpl] 816 Anamalamudi, S., Zhang, M., Perkins, C., Anand, S., and B. 817 Liu, "AODV based RPL Extensions for Supporting Asymmetric 818 P2P Links in Low-Power and Lossy Networks", draft-ietf- 819 roll-aodv-rpl-08 (work in progress), May 2020. 821 [I-D.ietf-roll-unaware-leaves] 822 Thubert, P. and M. Richardson, "Routing for RPL Leaves", 823 draft-ietf-roll-unaware-leaves-22 (work in progress), 824 October 2020. 826 [I-D.popa-6lo-6loplc-ipv6-over-ieee19012-networks] 827 Popa, D. and J. Hui, "6LoPLC: Transmission of IPv6 Packets 828 over IEEE 1901.2 Narrowband Powerline Communication 829 Networks", draft-popa-6lo-6loplc-ipv6-over- 830 ieee19012-networks-00 (work in progress), March 2014. 832 [IEEE_1901.2a] 833 IEEE-SA Standards Board, "IEEE Standard for Low-Frequency 834 (less than 500 kHz) Narrowband Power Line Communications 835 for Smart Grid Applications - Amendment 1", IEEE 1901.2a, 836 September 2015, . 839 [RFC3315] Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins, 840 C., and M. Carney, "Dynamic Host Configuration Protocol 841 for IPv6 (DHCPv6)", RFC 3315, DOI 10.17487/RFC3315, July 842 2003, . 844 [RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)", 845 RFC 3972, DOI 10.17487/RFC3972, March 2005, 846 . 848 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 849 Architecture", RFC 4291, DOI 10.17487/RFC4291, February 850 2006, . 852 [RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy 853 Extensions for Stateless Address Autoconfiguration in 854 IPv6", RFC 4941, DOI 10.17487/RFC4941, September 2007, 855 . 857 [RFC5191] Forsberg, D., Ohba, Y., Ed., Patil, B., Tschofenig, H., 858 and A. Yegin, "Protocol for Carrying Authentication for 859 Network Access (PANA)", RFC 5191, DOI 10.17487/RFC5191, 860 May 2008, . 862 [RFC5535] Bagnulo, M., "Hash-Based Addresses (HBA)", RFC 5535, 863 DOI 10.17487/RFC5535, June 2009, 864 . 866 [RFC7217] Gont, F., "A Method for Generating Semantically Opaque 867 Interface Identifiers with IPv6 Stateless Address 868 Autoconfiguration (SLAAC)", RFC 7217, 869 DOI 10.17487/RFC7217, April 2014, 870 . 872 [RFC7925] Tschofenig, H., Ed. and T. Fossati, "Transport Layer 873 Security (TLS) / Datagram Transport Layer Security (DTLS) 874 Profiles for the Internet of Things", RFC 7925, 875 DOI 10.17487/RFC7925, July 2016, 876 . 878 [RFC8036] Cam-Winget, N., Ed., Hui, J., and D. Popa, "Applicability 879 Statement for the Routing Protocol for Low-Power and Lossy 880 Networks (RPL) in Advanced Metering Infrastructure (AMI) 881 Networks", RFC 8036, DOI 10.17487/RFC8036, January 2017, 882 . 884 [RFC8064] Gont, F., Cooper, A., Thaler, D., and W. Liu, 885 "Recommendation on Stable IPv6 Interface Identifiers", 886 RFC 8064, DOI 10.17487/RFC8064, February 2017, 887 . 889 [RFC8065] Thaler, D., "Privacy Considerations for IPv6 Adaptation- 890 Layer Mechanisms", RFC 8065, DOI 10.17487/RFC8065, 891 February 2017, . 893 Authors' Addresses 895 Jianqiang Hou 896 Huawei Technologies 897 101 Software Avenue, 898 Nanjing 210012 899 China 901 Email: houjianqiang@huawei.com 902 Bing Liu 903 Huawei Technologies 904 No. 156 Beiqing Rd. Haidian District, 905 Beijing 100095 906 China 908 Email: remy.liubing@huawei.com 910 Yong-Geun Hong 911 Electronics and Telecommunications Research Institute 912 161 Gajeong-Dong Yuseung-Gu 913 Daejeon 305-700 914 Korea 916 Email: yghong@etri.re.kr 918 Xiaojun Tang 919 State Grid Electric Power Research Institute 920 19 Chengxin Avenue 921 Nanjing 211106 922 China 924 Email: itc@sgepri.sgcc.com.cn 926 Charles E. Perkins 928 Email: charliep@computer.org