idnits 2.17.1 draft-ietf-6lo-plc-01.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 date (November 3, 2019) is 1629 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 315, but not defined == Outdated reference: A later version (-18) exists of draft-ietf-roll-aodv-rpl-07 -- 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 (~~), 3 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 6, 2020 Y-G. Hong 6 ETRI 7 X. Tang 8 SGEPRI 9 C. Perkins 10 November 3, 2019 12 Transmission of IPv6 Packets over PLC Networks 13 draft-ietf-6lo-plc-01 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 6, 2020. 44 Copyright Notice 46 Copyright (c) 2019 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 . . . . . . . . . . . . . . . . . . . . . . . 4 64 3.1. Protocol Stack . . . . . . . . . . . . . . . . . . . . . 5 65 3.2. Addressing Modes . . . . . . . . . . . . . . . . . . . . 6 66 3.3. Maximum Transmission Unit . . . . . . . . . . . . . . . . 6 67 3.4. Routing Protocol . . . . . . . . . . . . . . . . . . . . 6 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 . . . . . . . . . . . . . . . . . 8 72 4.3.1. Unicast Address Mapping for IEEE 1901.1 . . . . . . . 8 73 4.3.2. Unicast Address Mapping for IEEE 1901.2 and ITU-T 74 G.9903 . . . . . . . . . . . . . . . . . . . . . . . 9 75 4.4. Neighbor Discovery . . . . . . . . . . . . . . . . . . . 10 76 4.5. Header Compression . . . . . . . . . . . . . . . . . . . 11 77 4.6. Fragmentation and Reassembly . . . . . . . . . . . . . . 11 78 5. Internet Connectivity Scenarios and Topologies . . . . . . . 12 79 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 80 7. Security Consideration . . . . . . . . . . . . . . . . . . . 14 81 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14 82 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 83 9.1. Normative References . . . . . . . . . . . . . . . . . . 15 84 9.2. Informative References . . . . . . . . . . . . . . . . . 16 85 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 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. Compared to 117 [I-D.popa-6lo-6loplc-ipv6-over-ieee19012-networks], this document 118 provides a structured and greatly expanded specification of an 119 adaptation layer for IPv6 over PLC (6LoPLC) networks. 121 2. Requirements Notation and Terminology 123 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 124 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 125 "OPTIONAL" in this document are to be interpreted as described in 126 [RFC2119]. 128 This document often uses the following acronyms and terminologies: 130 6LoWPAN: IPv6 over Low-Power Wireless Personal Area Network 132 AMI: Advanced Metering Infrastructure 134 BBPLC: Broadband Power Line Communication 136 CID: Context ID 138 Coordinator: A device capable of relaying messages. 140 DAD: Duplicate Address Detection 142 PAN device: An entity follows the PLC standards and implements the 143 protocol stack described in this draft. 145 EV: Electric Vehicle 147 IID: IPv6 Interface Identifier 149 IPHC: IP Header Compression 151 LAN: Local Area Network 153 MSDU: MAC Service Data Unit 155 MTU: Maximum Transmission Unit 157 NBPLC: Narrowband Power Line Communication 159 OFDM: Orthogonal Frequency Division Multiplexing 161 PANC: PAN Coordinator, a coordinator which also acts as the primary 162 controller of a PAN. 164 PLC: Power Line Communication 166 PSDU: PHY Service Data Unit 168 RPL: IPv6 Routing Protocol for Low-Power and Lossy Networks 170 RA: Router Advertisement 172 WAN: Wide Area Network 174 The terminology used in this draft is aligned with IEEE 1901.2 176 +-----------------+---------------------+----------------------+ 177 | IEEE 1901.2 | IEEE 1901.1 | ITU-T G.9903 | 178 +-----------------+---------------------+----------------------+ 179 | PAN Coordinator | Central Coordinator | PAN Coordinator | 180 | | | | 181 | Coordinator | Proxy Coordinator | Full-function device | 182 | | | | 183 | Device | Station | PAN Device | 184 +-----------------+---------------------+----------------------+ 186 Table 1: Terminology Mapping between PLC standards 188 3. Overview of PLC 190 PLC technology enables convenient two-way communications for home 191 users and utility companies to monitor and control electric plugged 192 devices such as electricity meters and street lights. Due to the 193 large range of communication frequencies, PLC is generally classified 194 into two categories: Narrowband PLC (NBPLC) for automation of sensors 195 (which have low frequency band and low power cost), and Broadband PLC 196 (BBPLC) for home and industry networking applications. Various 197 standards have been addressed on the MAC and PHY layers for this 198 communication technology, e.g. BBPLC (1.8-250 MHz) including IEEE 199 1901 and ITU-T G.hn, and NBPLC (3-500 kHz) including ITU-T G.9902 200 (G.hnem), ITU-T G.9903 (G3-PLC) [ITU-T_G.9903], ITU-T G.9904 (PRIME), 201 IEEE 1901.2 [IEEE_1901.2] (combination of G3-PLC and PRIME PLC) and 202 IEEE 1901.2a [IEEE_1901.2a] (an amendment to IEEE 1901.2). Moreover, 203 recently a new PLC standard IEEE 1901.1 [IEEE_1901.1], which aims at 204 the medium frequency band less than 12 MHz, has been published by the 205 IEEE standard for Smart Grid Powerline Communication Working Group 206 (SGPLC WG). IEEE 1901.1 balances the needs for bandwidth versus 207 communication range, and is thus a promising option for 6lo 208 applications. Currently, this specification is focused on IEEE 209 1901.1, IEEE 1901.2 and ITU-T G.9903. 211 3.1. Protocol Stack 213 The protocol stack for IPv6 over PLC is illustrated in Figure 1. The 214 PLC MAC/PHY layer corresponds to IEEE 1901.1, IEEE 1901.2 or ITU-T 215 G.9903. The 6lo adaptation layer for PLC is illustrated in 216 Section 4. For multihop tree and mesh topologies, a routing protocol 217 is likely to be necessary. The routes can be built in mesh-under 218 mode at layer 2 or in route-over mode at layer 3. 220 +----------------------------------------+ 221 | Application Layer | 222 +----------------------------------------+ 223 | TCP/UDP | 224 +----------------------------------------+ 225 | | 226 | IPv6 | 227 | | 228 +----------------------------------------+ 229 | Adaptation layer for IPv6 over PLC | 230 +----------------------------------------+ 231 | PLC MAC Layer | 232 +----------------------------------------+ 233 | PLC PHY Layer | 234 +----------------------------------------+ 236 Figure 1: PLC Protocol Stack 238 3.2. Addressing Modes 240 Each PLC device has a globally unique long address of 48-bit 241 ([IEEE_1901.1]) or 64-bit ([IEEE_1901.2], [ITU-T_G.9903]) and a short 242 address of 12-bit ([IEEE_1901.1]) or 16-bit ([IEEE_1901.2], 243 [ITU-T_G.9903]). The long address is set by the manufacturer 244 according to the IEEE EUI-48 MAC address or the IEEE EUI-64 address. 245 Each PLC device joins the network by using the long address and 246 communicates with other devices by using the short address after 247 joining the network. 249 3.3. Maximum Transmission Unit 251 The Maximum Transmission Unit (MTU) of the MAC layer determines 252 whether fragmentation and reassembly are needed at the adaptation 253 layer of IPv6 over PLC. IPv6 requires an MTU of 1280 octets or 254 greater; thus for a MAC layer with MTU lower than this limit, 255 fragmentation and reassembly at the adaptation layer are required. 257 The IEEE 1901.1 MAC supports upper layer packets up to 2031 octets. 258 The IEEE 1901.2 MAC layer supports the MTU of 1576 octets (the 259 original value of 1280 bytes was updated in 2015 [IEEE_1901.2a]). 260 Though fragmentation and reassembly are not needed in these two 261 technologies, other 6lo functions like header compression are still 262 applicable and useful, particularly in high-noise communication 263 environments. 265 The MTU for ITU-T G.9903 is 400 octets, insufficient for supporting 266 IPv6's MTU. For this reason, fragmentation and reassembly as per 267 [RFC4944] MUST be enabled for G.9903-based networks. 269 3.4. Routing Protocol 271 Routing protocols suitable for use in PLC networks include: 273 o RPL (Routing Protocol for Low-Power and Lossy Networks) [RFC6550] 274 is a layer 3 routing protocol. AODV-RPL [I-D.ietf-roll-aodv-rpl] 275 updates RPL to include reactive, point-to-point, and asymmetric 276 routing. IEEE 1901.2 specifies Information Elements (IEs) with 277 MAC layer metrics, which can be provided to L3 routing protocol 278 for parent selection. For IPv6-addressable PLC networks, a 279 layer-3 routing protocol such as RPL and/or AODV-RPL SHOULD be 280 supported in the standard. 282 o IEEE 1901.1 supports L2 routing. Each PLC node maintains a L2 283 routing table, in which each route entry comprises the short 284 addresses of the destination and the related next hop. The route 285 entries are built during the network establishment via a pair of 286 association request/confirmation messages. The route entries can 287 be changed via a pair of proxy change request/confirmation 288 messages. These association and proxy change messages MUST be 289 approved by the central coordinator. 291 o LOADng is a reactive protocol operating at layer 2 or layer 3. 292 Currently, LOADng is supported in ITU-T G.9903 [ITU-T_G.9903], and 293 the IEEE 1901.2 standard refers to ITU-T G.9903 for LOAD-based 294 networks. 296 4. IPv6 over PLC 298 6LoWPAN standards [RFC4944], [RFC6775], and [RFC6282] provides useful 299 functionality including link-local IPv6 addresses, stateless address 300 auto-configuration, neighbor discovery and header compression. 301 However, due to the different characteristics of the PLC media, the 302 6LoWPAN adaptation layer cannot perfectly fulfill the requirements. 303 Besides, some of the features like fragmentation and reassembly are 304 redudant to some PLC technologies. These considerations suggest the 305 need for a dedicated adaptation layer for PLC, which is detailed in 306 the following subsections. 308 4.1. Stateless Address Autoconfiguration 310 To obtain an IPv6 Interface Identifier (IID), a PLC device performs 311 stateless address autoconfiguration [RFC4944]. The autoconfiguration 312 can be based on either a long or short link-layer address. 314 The IID can be based on the device's 48-bit MAC address or its EUI-64 315 identifier [EUI-64]. A 48-bit MAC address MUST first be extended to 316 a 64-bit Interface ID by inserting 0xFFFE at the fourth and fifth 317 octets as specified in [RFC2464]. The IPv6 IID is derived from the 318 64-bit Interface ID by inverting the U/L bit [RFC4291]. 320 For IEEE 1901.2 and ITU-T G.9903, a 48-bit "pseudo-address" is formed 321 by the 16-bit PAN ID, 16 zero bits and the 16-bit short address. 322 Then, the 64-bit Interface ID MUST be derived by inserting 16-bit 323 0xFFFE into as follows: 325 16_bit_PAN:00FF:FE00:16_bit_short_address 327 For the 12-bit short addresses used by IEEE 1901.1, the 48-bit 328 pseudo-address is formed by 24-bit NID (Network IDentifier, YYYYYY), 329 12 zero bits and a 12-bit TEI (Terminal Equipment Identifier, XXX). 330 The 64-bit Interface ID MUST be derived by inserting 16-bit 0xFFFE 331 into this 48-bit pseudo-address as follows: 333 YYYY:YYFF:FE00:0XXX 335 Since the derived Interface ID is not global, the "Universal/Local" 336 (U/L) bit (7th bit) and the Individual/Group bit (8th bit) MUST both 337 be set to zero. In order to avoid any ambiguity in the derived 338 Interface ID, these two bits MUST NOT be used to generate the PANID 339 (for IEEE 1901.2 and ITU-T G.9903) or NID (for IEEE 1901.1). In 340 other words, the PANID or NID MUST always be chosen so that these 341 bits are zeros. 343 For privacy reasons, the IID derived by the MAC address SHOULD only 344 be used for link-local address configuration. A PLC host SHOULD use 345 the IID derived by the link-layer short address to configure the IPv6 346 address used for communication with the public network; otherwise, 347 the host's MAC address is exposed. 349 4.2. IPv6 Link Local Address 351 The IPv6 link-local address [RFC4291] for a PLC interface is formed 352 by appending the IID, as defined above, to the prefix FE80::/64 (see 353 Figure 2). 355 10 bits 54 bits 64 bits 356 +----------+-----------------------+----------------------------+ 357 |1111111010| (zeros) | Interface Identifier | 358 +----------+-----------------------+----------------------------+ 360 Figure 2: IPv6 Link Local Address for a PLC interface 362 4.3. Unicast Address Mapping 364 The address resolution procedure for mapping IPv6 unicast addresses 365 into PLC link-layer addresses follows the general description in 366 section 7.2 of [RFC4861]. [RFC6775] improves this procedure by 367 eliminating usage of multicast NS. The resolution is realized by the 368 NCEs (neighbor cache entry) created during the address registration 369 at the routers. [RFC8505] further improves the registration 370 procedure by enabling multiple LLNs to form an IPv6 subnet, and by 371 inserting a link-local address registration to better serve proxy 372 registration of new devices. 374 4.3.1. Unicast Address Mapping for IEEE 1901.1 376 The Source/Target Link-layer Address options for IEEE_1901.1 used in 377 the Neighbor Solicitation and Neighbor Advertisement have the 378 following form. 380 0 1 2 3 381 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 382 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 383 | Type | Length=1 | NID : 384 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 385 :NID (continued)| Padding (all zeros) | TEI | 386 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 388 Figure 3: Unicast Address Mapping for IEEE 1901.1 390 Option fields: 392 Type: 1 for Source Link-layer Address and 2 for Target Link-layer 393 Address. 395 Length: The length of this option (including type and length fields) 396 in units of 8 octets. The value of this field is 1 for the 397 12-bit IEEE 1901.1 PLC short addresses. 399 NID: 24-bit Network IDentifier 401 Padding: 12 zero bits 403 TEI: 12-bit Terminal Equipment Identifier 405 In order to avoid the possibility of duplicated IPv6 addresses, the 406 value of the NID MUST be chosen so that the 7th and 8th bits of the 407 first byte of the NID are both zero. 409 4.3.2. Unicast Address Mapping for IEEE 1901.2 and ITU-T G.9903 411 The Source/Target Link-layer Address options for IEEE_1901.2 and 412 ITU-T G.9903 used in the Neighbor Solicitation and Neighbor 413 Advertisement have the following form. 415 0 1 2 3 416 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 417 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 418 | Type | Length=1 | PAN ID | 419 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 420 | Padding (all zeros) | Short Address | 421 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 423 Figure 4: Unicast Address Mapping for IEEE 1901.2 425 Option fields: 427 Type: 1 for Source Link-layer Address and 2 for Target Link-layer 428 Address. 430 Length: The length of this option (including type and length fields) 431 in units of 8 octets. The value of this field is 1 for the 432 16-bit IEEE 1901.2 PLC short addresses. 434 PAN ID: 16-bit PAN IDentifier 436 Padding: 16 zero bits 438 Short Address: 16-bit short address 440 In order to avoid the possibility of duplicated IPv6 addresses, the 441 value of the PAN ID MUST be chosen so that the 7th and 8th bits of 442 the first byte of the PAN ID are both zero. 444 4.4. Neighbor Discovery 446 Neighbor discovery procedures for 6LoWPAN networks are described in 447 Neighbor Discovery Optimization for 6LoWPANs [RFC6775] and [RFC8505]. 448 These optimizations support the registration of sleeping hosts. 449 Although PLC devices are electrically powered, sleeping mode SHOULD 450 still be used for power saving. 452 For IPv6 address prefix dissemination, Router Solicitations (RS) and 453 Router Advertisements (RA) MAY be used as per [RFC6775]. If the PLC 454 network uses route-over mesh, the IPv6 prefix MAY be disseminated by 455 the layer 3 routing protocol, such as RPL which includes the prefix 456 in the DIO message. In this case, the prefix information option 457 (PIO) MUST NOT be included in the Router Advertisement. 459 For context information dissemination, Router Advertisements (RA) 460 MUST be used as per [RFC6775]. The 6LoWPAN context option (6CO) MUST 461 be included in the RA to disseminate the Context IDs used for prefix 462 compression. 464 For address registration in route-over mode, a PLC device MUST 465 register its addresses by sending unicast link-local Neighbor 466 Solicitation to the 6LR. If the registered address is link-local, 467 the 6LR SHOULD NOT further register it to the registrar (6LBR, 6BBR). 468 Otherwise, the address MUST be registered via an ARO or EARO included 469 in the DAR ([RFC6775]) or EDAR ([RFC8505]) messages. For RFC8505 470 compliant PLC devices, the 'R' flag in the EARO MUST be set when 471 sending Neighbor Solicitaitons in order to extract the status 472 information in the replied Neighbor Advertisements from the 6LR. If 473 DHCPv6 is used to assign addresses or the IPv6 address is derived by 474 unique long or short link layer address, Duplicate Address Detection 475 (DAD) MUST NOT be utilized. Otherwise, the DAD MUST be performed at 476 the 6LBR (as per [RFC6775]) or proxied by the routing registrar (as 477 per [RFC8505]). The registration status is feedbacked via the DAC or 478 EDAC message from the 6LBR and the Neighbor Advertisement (NA) from 479 the 6LR. 481 For address registration in mesh-under mode, since all the PLC 482 devices are the link-local neighbors to the 6LBR, DAR/DAC or EDAR/ 483 EDAC messages are not required. A PLC device MUST register its 484 addresses by sending the unicast NS message with an ARO or EARO. The 485 registration status is feedbacked via the NA message from the 6LBR. 487 4.5. Header Compression 489 The compression of IPv6 datagrams within PLC MAC frames refers to 490 [RFC6282], which updates [RFC4944]. Header compression as defined in 491 [RFC6282] which specifies the compression format for IPv6 datagrams 492 on top of IEEE 802.15.4, is included in this document as the basis 493 for IPv6 header compression in PLC. For situations when PLC MAC MTU 494 cannot support the 1280-octet IPv6 packet, headers MUST be compressed 495 according to [RFC6282] encoding formats. 497 4.6. Fragmentation and Reassembly 499 PLC differs from other wired technologies in that the communication 500 medium is not shielded; thus, to successfully transmit data through 501 power lines, PLC Data Link layer provides the function of 502 segmentation and reassembly. A Segment Control Field is defined in 503 the MAC frame header regardless of whether segmentation is required. 504 The number of data octets of the PHY payload can change dynamically 505 based on channel conditions, thus the MAC payload segmentation in the 506 MAC sublayer is enabled and guarantees a reliable one-hop data 507 transmission. Fragmentation and reassembly is still required at the 508 adaptation layer, if the MAC layer cannot support the minimum MTU 509 demanded by IPv6, which is 1280 octets. 511 In IEEE 1901.1 and IEEE 1901.2, since the MAC layer supports payloads 512 of 2031 octets and 1576 octets respectively, fragmentation is not 513 needed for IPv6 packet transmission. The fragmentation and 514 reassembly defined in [RFC4944] SHOULD NOT be used in the 6lo 515 adaptation layer of IEEE 1901.2. 517 In ITU-T G.9903, the maximum MAC payload size is fixed to 400 octets, 518 so to cope with the required MTU of 1280 octets by IPv6, 519 fragmentation and reassembly at 6lo adaptation layer MUST be provided 520 referring to [RFC4944]. 522 5. Internet Connectivity Scenarios and Topologies 524 The network model can be simplified to two kinds of network devices: 525 PAN Coordinator (PANC) and PAN Device. The PANC is the primary 526 coordinator of the PLC subnet and can be seen as a master node; PAN 527 Devices are typically PLC meters and sensors. The PANC also serves 528 as the Routing Registrar for proxy registration and DAD procedures, 529 making use of the updated registration procedures in [RFC8505]. IPv6 530 over PLC networks are built as tree, mesh or star according to the 531 use cases. Every network requires at least one PANC to communicate 532 with each PAN Device. Note that the PLC topologies in this section 533 are based on logical connectivity, not physical links. 535 The star topology is common in current PLC scenarios. In single-hop 536 star topologies, communication at the link layer only takes place 537 between a PAN Device and a PANC. The PANC typically collects data 538 (e.g. a meter reading) from the PAN devices, and then concentrates 539 and uploads the data through Ethernet or LPWAN (see Figure 5). The 540 collected data is transmitted by the smart meters through PLC, 541 aggregated by a concentrator, sent to the utility and then to a Meter 542 Data Management System for data storage, analysis and billing. This 543 topology has been widely applied in the deployment of smart meters, 544 especially in apartment buildings. 546 PAN Device PAN Device 547 \ / +--------- 548 \ / / 549 \ / + 550 \ / | 551 PAN Device ------ PANC ===========+ Internet 552 / \ | 553 / \ + 554 / \ \ 555 / \ +--------- 556 PAN Device PAN Device 558 <----------------------> 559 PLC subnet (IPv6 over PLC) 561 Figure 5: PLC Star Network connected to the Internet 563 A tree topology is useful when the distance between a device A and 564 PANC is beyond the PLC allowed limit and there is another device B in 565 between able to communicate with both sides. Device B in this case 566 acts both as a PAN Device and a Coordinator. For this scenario, the 567 link layer communications take place between device A and device B, 568 and between device B and PANC. An example of PLC tree network is 569 depicted in Figure 6. This topology can be applied in the smart 570 street lighting, where the lights adjust the brightness to reduce 571 energy consumption while sensors are deployed on the street lights to 572 provide information such as light intensity, temperature, humidity. 573 Data transmission distance in the street lighting scenario is 574 normally above several kilometers thus the PLC tree network is 575 required. A more sophisticated AMI network may also be constructed 576 into the tree topology which is depicted in [RFC8036]. A tree 577 topology is suitable for AMI scenarios that require large coverage 578 but low density, e.g. the deployment of smart meters in rural areas. 579 RPL is suitable for maintenance of a tree topology in which there is 580 no need for communication directly between PAN devices. 582 PAN Device 583 \ +--------- 584 PAN Device \ / 585 \ \ + 586 \ \ | 587 PAN Device -- PANC ===========+ Internet 588 / / | 589 / / + 590 PAN Device---PAN Device / \ 591 / +--------- 592 PAN Device---PAN Device 594 <-------------------------> 595 PLC subnet (IPv6 over PLC) 597 Figure 6: PLC Tree Network connected to the Internet 599 Mesh networking in PLC is of great potential applications and has 600 been studied for several years. By connecting all nodes with their 601 neighbors in communication range (see Figure 7), mesh topology 602 dramatically enhances the communication efficiency and thus expands 603 the size of PLC networks. A simple use case is the smart home 604 scenario where the ON/OFF state of air conditioning is controlled by 605 the state of home lights (ON/OFF) and doors (OPEN/CLOSE). AODV-RPL 606 enables direct PAN device to PAN device communication, without being 607 obliged to transmit frames through the PANC, which is a requirement 608 often cited for AMI infrastructure. 610 PAN Device---PAN Device 611 / \ / \ +--------- 612 / \ / \ / 613 / \ / \ + 614 / \ / \ | 615 PAN Device--PAN Device---PANC ===========+ Internet 616 \ / \ / | 617 \ / \ / + 618 \ / \ / \ 619 \ / \ / +--------- 620 PAN Device---PAN Device 622 <-------------------------------> 623 PLC subnet (IPv6 over PLC) 625 Figure 7: PLC Mesh Network connected to the Internet 627 6. IANA Considerations 629 There are no IANA considerations related to this document. 631 7. Security Consideration 633 Due to the high accessibility of power grid, PLC might be susceptible 634 to eavesdropping within its communication coverage, e.g. one 635 apartment tenant may have the chance to monitor the other smart 636 meters in the same apartment building. For security consideration, 637 link layer security is guaranteed in every PLC technology. 639 IP addresses may be used to track devices on the Internet; such 640 devices can in turn be linked to individuals and their activities. 641 Depending on the application and the actual use pattern, this may be 642 undesirable. To impede tracking, globally unique and non-changing 643 characteristics of IP addresses should be avoided, e.g., by 644 frequently changing the global prefix and avoiding unique link-layer 645 derived IIDs in addresses. [RFC3315], [RFC3972], [RFC4941], 646 [RFC5535], [RFC7217], and [RFC8065] provide valuable information for 647 IID formation with improved privacy, and are RECOMMENDED for IPv6 648 networks. 650 8. Acknowledgements 652 We gratefully acknowledge suggestions from the members of the IETF 653 6lo working group. Great thanks to Samita Chakrabarti and Gabriel 654 Montenegro for their feedback and support in connecting the IEEE and 655 ITU-T sides. Authors thank Scott Mansfield, Ralph Droms, Pat Kinney 656 for their guidance in the liaison process. Authors wish to thank 657 Stefano Galli, Thierry Lys, Yizhou Li and Yuefeng Wu for their 658 valuable comments and contributions. 660 9. References 662 9.1. Normative References 664 [IEEE_1901.1] 665 IEEE-SA Standards Board, "Standard for Medium Frequency 666 (less than 15 MHz) Power Line Communications for Smart 667 Grid Applications", IEEE 1901.1, May 2018, 668 . 670 [IEEE_1901.2] 671 IEEE-SA Standards Board, "IEEE Standard for Low-Frequency 672 (less than 500 kHz) Narrowband Power Line Communications 673 for Smart Grid Applications", IEEE 1901.2, October 2013, 674 . 677 [ITU-T_G.9903] 678 International Telecommunication Union, "Narrowband 679 orthogonal frequency division multiplexing power line 680 communication transceivers for G3-PLC networks", 681 ITU-T G.9903, February 2014, 682 . 684 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 685 Requirement Levels", BCP 14, RFC 2119, 686 DOI 10.17487/RFC2119, March 1997, 687 . 689 [RFC2464] Crawford, M., "Transmission of IPv6 Packets over Ethernet 690 Networks", RFC 2464, DOI 10.17487/RFC2464, December 1998, 691 . 693 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 694 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 695 DOI 10.17487/RFC4861, September 2007, 696 . 698 [RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler, 699 "Transmission of IPv6 Packets over IEEE 802.15.4 700 Networks", RFC 4944, DOI 10.17487/RFC4944, September 2007, 701 . 703 [RFC6282] Hui, J., Ed. and P. Thubert, "Compression Format for IPv6 704 Datagrams over IEEE 802.15.4-Based Networks", RFC 6282, 705 DOI 10.17487/RFC6282, September 2011, 706 . 708 [RFC6550] Winter, T., Ed., Thubert, P., Ed., Brandt, A., Hui, J., 709 Kelsey, R., Levis, P., Pister, K., Struik, R., Vasseur, 710 JP., and R. Alexander, "RPL: IPv6 Routing Protocol for 711 Low-Power and Lossy Networks", RFC 6550, 712 DOI 10.17487/RFC6550, March 2012, 713 . 715 [RFC6775] Shelby, Z., Ed., Chakrabarti, S., Nordmark, E., and C. 716 Bormann, "Neighbor Discovery Optimization for IPv6 over 717 Low-Power Wireless Personal Area Networks (6LoWPANs)", 718 RFC 6775, DOI 10.17487/RFC6775, November 2012, 719 . 721 [RFC8505] Thubert, P., Ed., Nordmark, E., Chakrabarti, S., and C. 722 Perkins, "Registration Extensions for IPv6 over Low-Power 723 Wireless Personal Area Network (6LoWPAN) Neighbor 724 Discovery", RFC 8505, DOI 10.17487/RFC8505, November 2018, 725 . 727 9.2. Informative References 729 [I-D.ietf-roll-aodv-rpl] 730 Anamalamudi, S., Zhang, M., Perkins, C., Anand, S., and B. 731 Liu, "Asymmetric AODV-P2P-RPL in Low-Power and Lossy 732 Networks (LLNs)", draft-ietf-roll-aodv-rpl-07 (work in 733 progress), April 2019. 735 [I-D.popa-6lo-6loplc-ipv6-over-ieee19012-networks] 736 Popa, D. and J. Hui, "6LoPLC: Transmission of IPv6 Packets 737 over IEEE 1901.2 Narrowband Powerline Communication 738 Networks", draft-popa-6lo-6loplc-ipv6-over- 739 ieee19012-networks-00 (work in progress), March 2014. 741 [IEEE_1901.2a] 742 IEEE-SA Standards Board, "IEEE Standard for Low-Frequency 743 (less than 500 kHz) Narrowband Power Line Communications 744 for Smart Grid Applications - Amendment 1", IEEE 1901.2a, 745 September 2015, . 748 [RFC3315] Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins, 749 C., and M. Carney, "Dynamic Host Configuration Protocol 750 for IPv6 (DHCPv6)", RFC 3315, DOI 10.17487/RFC3315, July 751 2003, . 753 [RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)", 754 RFC 3972, DOI 10.17487/RFC3972, March 2005, 755 . 757 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 758 Architecture", RFC 4291, DOI 10.17487/RFC4291, February 759 2006, . 761 [RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy 762 Extensions for Stateless Address Autoconfiguration in 763 IPv6", RFC 4941, DOI 10.17487/RFC4941, September 2007, 764 . 766 [RFC5535] Bagnulo, M., "Hash-Based Addresses (HBA)", RFC 5535, 767 DOI 10.17487/RFC5535, June 2009, 768 . 770 [RFC7217] Gont, F., "A Method for Generating Semantically Opaque 771 Interface Identifiers with IPv6 Stateless Address 772 Autoconfiguration (SLAAC)", RFC 7217, 773 DOI 10.17487/RFC7217, April 2014, 774 . 776 [RFC8036] Cam-Winget, N., Ed., Hui, J., and D. Popa, "Applicability 777 Statement for the Routing Protocol for Low-Power and Lossy 778 Networks (RPL) in Advanced Metering Infrastructure (AMI) 779 Networks", RFC 8036, DOI 10.17487/RFC8036, January 2017, 780 . 782 [RFC8065] Thaler, D., "Privacy Considerations for IPv6 Adaptation- 783 Layer Mechanisms", RFC 8065, DOI 10.17487/RFC8065, 784 February 2017, . 786 Authors' Addresses 788 Jianqiang Hou 789 Huawei Technologies 790 101 Software Avenue, 791 Nanjing 210012 792 China 794 Email: houjianqiang@huawei.com 795 Bing Liu 796 Huawei Technologies 797 No. 156 Beiqing Rd. Haidian District, 798 Beijing 100095 799 China 801 Email: remy.liubing@huawei.com 803 Yong-Geun Hong 804 Electronics and Telecommunications Research Institute 805 161 Gajeong-Dong Yuseung-Gu 806 Daejeon 305-700 807 Korea 809 Email: yghong@etri.re.kr 811 Xiaojun Tang 812 State Grid Electric Power Research Institute 813 19 Chengxin Avenue 814 Nanjing 211106 815 China 817 Email: itc@sgepri.sgcc.com.cn 819 Charles E. Perkins 821 Email: charliep@computer.org