idnits 2.17.1 draft-ietf-6lo-plc-00.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 (February 1, 2019) is 1904 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 == Missing Reference: 'ITU-T G.9905' is mentioned on line 542, but not defined == Outdated reference: A later version (-18) exists of draft-ietf-roll-aodv-rpl-05 -- 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 (~~), 4 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: August 5, 2019 Y-G. Hong 6 ETRI 7 X. Tang 8 SGEPRI 9 C. Perkins 10 Futurewei 11 February 1, 2019 13 Transmission of IPv6 Packets over PLC Networks 14 draft-ietf-6lo-plc-00 16 Abstract 18 Power Line Communication (PLC), namely using the electric-power lines 19 for indoor and outdoor communications, has been widely applied to 20 support Advanced Metering Infrastructure (AMI), especially smart 21 meters for electricity. The inherent advantage of existing 22 electricity infrastructure facilitates the expansion of PLC 23 deployments, and moreover, a wide variety of accessible devices 24 raises the potential demand of IPv6 for future applications. This 25 document describes how IPv6 packets are transported over constrained 26 PLC networks, such as ITU-T G.9903, IEEE 1901.1 and IEEE 1901.2. 28 Status of This Memo 30 This Internet-Draft is submitted in full conformance with the 31 provisions of BCP 78 and BCP 79. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF). Note that other groups may also distribute 35 working documents as Internet-Drafts. The list of current Internet- 36 Drafts is at https://datatracker.ietf.org/drafts/current/. 38 Internet-Drafts are draft documents valid for a maximum of six months 39 and may be updated, replaced, or obsoleted by other documents at any 40 time. It is inappropriate to use Internet-Drafts as reference 41 material or to cite them other than as "work in progress." 43 This Internet-Draft will expire on August 5, 2019. 45 Copyright Notice 47 Copyright (c) 2019 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents 52 (https://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with respect 55 to this document. Code Components extracted from this document must 56 include Simplified BSD License text as described in Section 4.e of 57 the Trust Legal Provisions and are provided without warranty as 58 described in the Simplified BSD License. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 63 2. Requirements Notation and Terminology . . . . . . . . . . . . 3 64 3. Overview of PLC . . . . . . . . . . . . . . . . . . . . . . . 5 65 3.1. Protocol Stack . . . . . . . . . . . . . . . . . . . . . 5 66 3.2. Addressing Modes . . . . . . . . . . . . . . . . . . . . 6 67 3.3. Maximum Transmission Unit . . . . . . . . . . . . . . . . 6 68 3.4. Routing Protocol . . . . . . . . . . . . . . . . . . . . 7 69 4. IPv6 over PLC . . . . . . . . . . . . . . . . . . . . . . . . 7 70 4.1. Stateless Address Autoconfiguration . . . . . . . . . . . 7 71 4.2. IPv6 Link Local Address . . . . . . . . . . . . . . . . . 8 72 4.3. Unicast Address Mapping . . . . . . . . . . . . . . . . . 9 73 4.3.1. Unicast Address Mapping for IEEE 1901.1 . . . . . . . 9 74 4.3.2. Unicast Address Mapping for IEEE 1901.2 and ITU-T 75 G.9903 . . . . . . . . . . . . . . . . . . . . . . . 10 76 4.4. Neighbor Discovery . . . . . . . . . . . . . . . . . . . 10 77 4.5. Header Compression . . . . . . . . . . . . . . . . . . . 11 78 4.6. Fragmentation and Reassembly . . . . . . . . . . . . . . 11 79 4.7. Extension at 6lo Adaptation Layer . . . . . . . . . . . . 12 80 5. Internet Connectivity Scenarios and Topologies . . . . . . . 13 81 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 82 7. Security Consideration . . . . . . . . . . . . . . . . . . . 16 83 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 16 84 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 85 9.1. Normative References . . . . . . . . . . . . . . . . . . 16 86 9.2. Informative References . . . . . . . . . . . . . . . . . 18 87 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19 89 1. Introduction 91 The idea of using power lines for both electricity supply and 92 communication can be traced back to the beginning of the last 93 century. With the advantage of existing power grid, Power Line 94 Communication (PLC) is a good candidate for supporting various 95 service scenarios such as in houses and offices, in trains and 96 vehicles, in smart grid and advanced metering infrastructure (AMI). 97 The data acquisition devices in these scenarios share common features 98 such as fixed position, large quantity, low data rate and low power 99 consumption. 101 Although PLC technology has evolved over several decades, it has not 102 been fully adapted for IPv6 based constrained networks. The 6lo 103 related scenarios lie in the low voltage PLC networks with most 104 applications in the area of Advanced Metering Infrastructure (AMI), 105 Vehicle-to-Grid communications, in-home energy management and smart 106 street lighting. IPv6 is important for PLC networks, due to its 107 large address space and efficent address auto-configuration. A 108 comparison among various existing PLC standards is provided to 109 facilitate the selection of the most applicable standard in 110 particular scenarios. 112 This specification provides a brief overview of PLC technologies. 113 Some of them have LLN characteristics, i.e. limited power 114 consumption, memory and processing resources. This specification is 115 focused on the transmission of IPv6 packets over those "constrained" 116 PLC networks. The general approach is to adapt elements of the 117 6LoWPAN specifications [RFC4944], [RFC6282], and [RFC6775] to 118 constrained PLC networks. Compared to 119 [I-D.popa-6lo-6loplc-ipv6-over-ieee19012-networks], this document 120 provides a structured and greatly expanded specification of an 121 adaptation layer for IPv6 over PLC (6LoPLC) networks. 123 2. Requirements Notation and Terminology 125 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 126 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 127 "OPTIONAL" in this document are to be interpreted as described in 128 [RFC2119]. 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 137 CID: Context ID 139 Coordinator: A device capable of relaying messages. 141 DAD: Duplicate Address Detection 143 PAN device: An entity follows the PLC standards and implements the 144 protocol stack described in this draft. 146 EV: Electric Vehicle 148 IID: IPv6 Interface Identifier 150 IPHC: IP Header Compression 152 LAN: Local Area Network 154 MSDU: MAC Service Data Unit 156 MTU: Maximum Transmission Unit 158 NBPLC: Narrowband Power Line Communication 160 OFDM: Orthogonal Frequency Division Multiplexing 162 PANC: PAN Coordinator, a coordinator which also acts as the primary 163 controller of a PAN. 165 PLC: Power Line Communication 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 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. 6775-update 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 448 [I-D.ietf-6lo-rfc6775-update]. These optimizations support the 449 registration of sleeping hosts. Although PLC devices are 450 electrically powered, sleeping mode SHOULD still be used for power 451 saving. 453 For IPv6 address prefix dissemination, Router Solicitations (RS) and 454 Router Advertisements (RA) MAY be used as per [RFC6775]. If the PLC 455 network uses route-over mesh, the IPv6 prefix MAY be disseminated by 456 the layer 3 routing protocol, such as RPL which includes the prefix 457 in the DIO message. In this case, the prefix information option 458 (PIO) MUST NOT be included in the Router Advertisement. 460 For context information dissemination, Router Advertisements (RA) 461 MUST be used as per [RFC6775]. The 6LoWPAN context option (6CO) MUST 462 be included in the RA to disseminate the Context IDs used for prefix 463 compression. 465 For address registration, a PLC host MUST register its address to the 466 router using Neighbor Solicitation and Neighbor Advertisement 467 messages. RFC6775-update PLC devices MUST include the EARO with the 468 'R' flag set when sending Neighbor Solicitations, and process 469 Neighbor Advertisements that include EARO to extract status 470 information. If DHCPv6 is used to assign addresses, or the IPv6 471 address is derived by unique long or short link layer address, 472 Duplicate Address Detection (DAD) MUST NOT be utilized. Otherwise, 473 DAD MUST be performed: RFC6775-only PLC devices MUST perform multihop 474 DAD against a 6LBR by using DAR and DAC messages, while for 475 RFC6775-update devices, DAD is proxied by a routing registrar, which 476 MAY operate according to Optimistic DAD (ODAD) [RFC4429]. 478 The mesh-under ITU-T G.9903 network SHOULD NOT utilize the address 479 registration as described in [RFC6775]. ITU-T G.9903 PLC networks 480 MUST use the 6LoWPAN Context Option (6CO) specified in [RFC6775] (see 481 clause 9.4.1.1 in [ITU-T_G.9903]), which can be attached in Router 482 Advertisements to disseminate Context IDs (CIDs) to use for 483 compressing prefixes. 485 4.5. Header Compression 487 The compression of IPv6 datagrams within PLC MAC frames refers to 488 [RFC6282], which updates [RFC4944]. Header compression as defined in 489 [RFC6282] which specifies the compression format for IPv6 datagrams 490 on top of IEEE 802.15.4, is included in this document as the basis 491 for IPv6 header compression in PLC. For situations when PLC MAC MTU 492 cannot support the 1280-octet IPv6 packet, headers MUST be compressed 493 according to [RFC6282] encoding formats. 495 4.6. Fragmentation and Reassembly 497 PLC differs from other wired technologies in that the communication 498 medium is not shielded; thus, to successfully transmit data through 499 power lines, PLC Data Link layer provides the function of 500 segmentation and reassembly. A Segment Control Field is defined in 501 the MAC frame header regardless of whether segmentation is required. 502 The number of data octets of the PHY payload can change dynamically 503 based on channel conditions, thus the MAC payload segmentation in the 504 MAC sublayer is enabled and guarantees a reliable one-hop data 505 transmission. Fragmentation and reassembly is still required at the 506 adaptation layer, if the MAC layer cannot support the minimum MTU 507 demanded by IPv6, which is 1280 octets. 509 In IEEE 1901.1 and IEEE 1901.2, since the MAC layer supports payloads 510 of 2031 octets and 1576 octets respectively, fragmentation is not 511 needed for IPv6 packet transmission. The fragmentation and 512 reassembly defined in [RFC4944] SHOULD NOT be used in the 6lo 513 adaptation layer of IEEE 1901.2. 515 In ITU-T G.9903, the maximum MAC payload size is fixed to 400 octets, 516 so to cope with the required MTU of 1280 octets by IPv6, 517 fragmentation and reassembly at 6lo adaptation layer MUST be provided 518 referring to [RFC4944]. 520 4.7. Extension at 6lo Adaptation Layer 522 Apart from the Dispatch and LOWPAN_IPHC headers specified in 523 [RFC4944], an additional Command Frame Header is needed for the mesh 524 routing procedure in LOADng protocol. Figure 5 illustrates the 525 format of the Command Frame Header [RFC8066]. The ESC dispatch type 526 (01000000b) indicates an ESC extension type follows (see [RFC4944] 527 and [RFC6282]). Then this 1-octet dispatch field is used as the 528 Command Frame Header and filled with the Command ID. The Command ID 529 can be classified into 4 types: 531 o LOADng message (0x01) 533 o LoWPAN bootstrapping protocol message (0x02) 535 o Reserved by ITU-T (0x03-0x0F) 537 o CMSR protocol messages (0X10-0X1F) 539 The LOADng message is used to provide the default routing protocol 540 LOADng while the LoWPAN bootstrapping protocol message is for the 541 LoWPAN bootstrap procedure. The CMSR protocol messages are specified 542 for the Centralized metric-based source routing [ITU-T G.9905] which 543 is out of the scope of this draft. 545 0 1 2 3 546 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 547 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 548 | ESC | Command ID | Command Payload 549 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 551 Figure 5: Command Frame Header Format of ITU-T G.9903 553 Command Frame Header appears in the last position if more than one 554 header is present in the 6LoWPAN frame [ITU-T_G.9903]. On the other 555 hand, this Command Frame Header MUST appear before the LoWPAN_IPHC 556 dispatch type as per[RFC8066]. 558 o Regarding the order of the command frame header, the inconsistency 559 between G.9903 and RFC8066 still exists and is being solved in 560 ITU-T SG15/Q15. 562 Following these two requirements of header order mentioned above, an 563 example of the header order is illustrated in Figure 6 including the 564 Fragmentation type, Fragmentation header, ESC dispatch type, ESC 565 Extension Type (Command ID), ESC Dispatch Payload (Command Payload), 566 LOWPAN_IPHC Dispatch Type, LOWPAN_IPHC header, and Payload. 568 +-----+-----+-----+-----+-----+--------+---------------+------+ 569 |F typ|F hdr| ESC | EET | EDP |Dispatch|LOWPAN_IPHC hdr| Payld| 570 +-----+-----+-----+-----+-----+--------+---------------+------+ 572 Figure 6: A 6LoWPAN packet including the Command Frame Header 574 5. Internet Connectivity Scenarios and Topologies 576 The network model can be simplified to two kinds of network devices: 577 PAN Coordinator (PANC) and PAN Device. The PANC is the primary 578 coordinator of the PLC subnet and can be seen as a master node; PAN 579 Devices are typically PLC meters and sensors. The PANC also serves 580 as the Routing Registrar for proxy registration and DAD procedures, 581 making use of the updated registration procedures in 582 [I-D.ietf-6lo-rfc6775-update]. IPv6 over PLC networks are built as 583 tree, mesh or star according to the use cases. Every network 584 requires at least one PANC to communicate with each PAN Device. Note 585 that the PLC topologies in this section are based on logical 586 connectivity, not physical links. 588 The star topology is common in current PLC scenarios. In single-hop 589 star topologies, communication at the link layer only takes place 590 between a PAN Device and a PANC. The PANC typically collects data 591 (e.g. a meter reading) from the PAN devices, and then concentrates 592 and uploads the data through Ethernet or LPWAN (see Figure 7). The 593 collected data is transmitted by the smart meters through PLC, 594 aggregated by a concentrator, sent to the utility and then to a Meter 595 Data Management System for data storage, analysis and billing. This 596 topology has been widely applied in the deployment of smart meters, 597 especially in apartment buildings. 599 PAN Device PAN Device 600 \ / +--------- 601 \ / / 602 \ / + 603 \ / | 604 PAN Device ------ PANC ===========+ Internet 605 / \ | 606 / \ + 607 / \ \ 608 / \ +--------- 609 PAN Device PAN Device 611 <----------------------> 612 PLC subnet (IPv6 over PLC) 614 Figure 7: PLC Star Network connected to the Internet 616 A tree topology is useful when the distance between a device A and 617 PANC is beyond the PLC allowed limit and there is another device B in 618 between able to communicate with both sides. Device B in this case 619 acts both as a PAN Device and a Coordinator. For this scenario, the 620 link layer communications take place between device A and device B, 621 and between device B and PANC. An example of PLC tree network is 622 depicted in Figure 8. This topology can be applied in the smart 623 street lighting, where the lights adjust the brightness to reduce 624 energy consumption while sensors are deployed on the street lights to 625 provide information such as light intensity, temperature, humidity. 626 Data transmission distance in the street lighting scenario is 627 normally above several kilometers thus the PLC tree network is 628 required. A more sophisticated AMI network may also be constructed 629 into the tree topology which is depicted in [RFC8036]. A tree 630 topology is suitable for AMI scenarios that require large coverage 631 but low density, e.g. the deployment of smart meters in rural areas. 632 RPL is suitable for maintenance of a tree topology in which there is 633 no need for communication directly between PAN devices. 635 PAN Device 636 \ +--------- 637 PAN Device \ / 638 \ \ + 639 \ \ | 640 PAN Device -- PANC ===========+ Internet 641 / / | 642 / / + 643 PAN Device---PAN Device / \ 644 / +--------- 645 PAN Device---PAN Device 647 <-------------------------> 648 PLC subnet (IPv6 over PLC) 650 Figure 8: PLC Tree Network connected to the Internet 652 Mesh networking in PLC is of great potential applications and has 653 been studied for several years. By connecting all nodes with their 654 neighbors in communication range (see Figure 9), mesh topology 655 dramatically enhances the communication efficiency and thus expands 656 the size of PLC networks. A simple use case is the smart home 657 scenario where the ON/OFF state of air conditioning is controlled by 658 the state of home lights (ON/OFF) and doors (OPEN/CLOSE). AODV-RPL 659 enables direct PAN device to PAN device communication, without being 660 obliged to transmit frames through the PANC, which is a requirement 661 often cited for AMI infrastructure. 663 PAN Device---PAN Device 664 / \ / \ +--------- 665 / \ / \ / 666 / \ / \ + 667 / \ / \ | 668 PAN Device--PAN Device---PANC ===========+ Internet 669 \ / \ / | 670 \ / \ / + 671 \ / \ / \ 672 \ / \ / +--------- 673 PAN Device---PAN Device 675 <-------------------------------> 676 PLC subnet (IPv6 over PLC) 678 Figure 9: PLC Mesh Network connected to the Internet 680 6. IANA Considerations 682 There are no IANA considerations related to this document. 684 7. Security Consideration 686 Due to the high accessibility of power grid, PLC might be susceptible 687 to eavesdropping within its communication coverage, e.g. one 688 apartment tenant may have the chance to monitor the other smart 689 meters in the same apartment building. For security consideration, 690 link layer security is guaranteed in every PLC technology. 692 IP addresses may be used to track devices on the Internet; such 693 devices can in turn be linked to individuals and their activities. 694 Depending on the application and the actual use pattern, this may be 695 undesirable. To impede tracking, globally unique and non-changing 696 characteristics of IP addresses should be avoided, e.g., by 697 frequently changing the global prefix and avoiding unique link-layer 698 derived IIDs in addresses. [RFC3315], [RFC3972], [RFC4941], 699 [RFC5535], [RFC7217], and [RFC8065] provide valuable information for 700 IID formation with improved privacy, and are RECOMMENDED for IPv6 701 networks. 703 8. Acknowledgements 705 We gratefully acknowledge suggestions from the members of the IETF 706 6lo working group. Great thanks to Samita Chakrabarti and Gabriel 707 Montenegro for their feedback and support in connecting the IEEE and 708 ITU-T sides. Authors thank Scott Mansfield, Ralph Droms, Pat Kinney 709 for their guidance in the liaison process. Authors wish to thank 710 Stefano Galli, Thierry Lys, Yizhou Li and Yuefeng Wu for their 711 valuable comments and contributions. 713 9. References 715 9.1. Normative References 717 [I-D.ietf-6lo-rfc6775-update] 718 Thubert, P., Nordmark, E., Chakrabarti, S., and C. 719 Perkins, "Registration Extensions for 6LoWPAN Neighbor 720 Discovery", draft-ietf-6lo-rfc6775-update-21 (work in 721 progress), June 2018. 723 [I-D.ietf-roll-aodv-rpl] 724 Anamalamudi, S., Zhang, M., Perkins, C., Anand, S., and B. 725 Liu, "Asymmetric AODV-P2P-RPL in Low-Power and Lossy 726 Networks (LLNs)", draft-ietf-roll-aodv-rpl-05 (work in 727 progress), October 2018. 729 [IEEE_1901.1] 730 IEEE-SA Standards Board, "Standard for Medium Frequency 731 (less than 15 MHz) Power Line Communications for Smart 732 Grid Applications", IEEE 1901.1, May 2018, 733 . 735 [IEEE_1901.2] 736 IEEE-SA Standards Board, "IEEE Standard for Low-Frequency 737 (less than 500 kHz) Narrowband Power Line Communications 738 for Smart Grid Applications", IEEE 1901.2, October 2013, 739 . 742 [ITU-T_G.9903] 743 International Telecommunication Union, "Narrowband 744 orthogonal frequency division multiplexing power line 745 communication transceivers for G3-PLC networks", 746 ITU-T G.9903, February 2014, 747 . 749 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 750 Requirement Levels", BCP 14, RFC 2119, 751 DOI 10.17487/RFC2119, March 1997, 752 . 754 [RFC2464] Crawford, M., "Transmission of IPv6 Packets over Ethernet 755 Networks", RFC 2464, DOI 10.17487/RFC2464, December 1998, 756 . 758 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 759 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 760 DOI 10.17487/RFC4861, September 2007, 761 . 763 [RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler, 764 "Transmission of IPv6 Packets over IEEE 802.15.4 765 Networks", RFC 4944, DOI 10.17487/RFC4944, September 2007, 766 . 768 [RFC6282] Hui, J., Ed. and P. Thubert, "Compression Format for IPv6 769 Datagrams over IEEE 802.15.4-Based Networks", RFC 6282, 770 DOI 10.17487/RFC6282, September 2011, 771 . 773 [RFC6550] Winter, T., Ed., Thubert, P., Ed., Brandt, A., Hui, J., 774 Kelsey, R., Levis, P., Pister, K., Struik, R., Vasseur, 775 JP., and R. Alexander, "RPL: IPv6 Routing Protocol for 776 Low-Power and Lossy Networks", RFC 6550, 777 DOI 10.17487/RFC6550, March 2012, 778 . 780 [RFC6775] Shelby, Z., Ed., Chakrabarti, S., Nordmark, E., and C. 781 Bormann, "Neighbor Discovery Optimization for IPv6 over 782 Low-Power Wireless Personal Area Networks (6LoWPANs)", 783 RFC 6775, DOI 10.17487/RFC6775, November 2012, 784 . 786 9.2. Informative References 788 [I-D.popa-6lo-6loplc-ipv6-over-ieee19012-networks] 789 Popa, D. and J. Hui, "6LoPLC: Transmission of IPv6 Packets 790 over IEEE 1901.2 Narrowband Powerline Communication 791 Networks", draft-popa-6lo-6loplc-ipv6-over- 792 ieee19012-networks-00 (work in progress), March 2014. 794 [IEEE_1901.2a] 795 IEEE-SA Standards Board, "IEEE Standard for Low-Frequency 796 (less than 500 kHz) Narrowband Power Line Communications 797 for Smart Grid Applications - Amendment 1", IEEE 1901.2a, 798 September 2015, . 801 [RFC3315] Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins, 802 C., and M. Carney, "Dynamic Host Configuration Protocol 803 for IPv6 (DHCPv6)", RFC 3315, DOI 10.17487/RFC3315, July 804 2003, . 806 [RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)", 807 RFC 3972, DOI 10.17487/RFC3972, March 2005, 808 . 810 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 811 Architecture", RFC 4291, DOI 10.17487/RFC4291, February 812 2006, . 814 [RFC4429] Moore, N., "Optimistic Duplicate Address Detection (DAD) 815 for IPv6", RFC 4429, DOI 10.17487/RFC4429, April 2006, 816 . 818 [RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy 819 Extensions for Stateless Address Autoconfiguration in 820 IPv6", RFC 4941, DOI 10.17487/RFC4941, September 2007, 821 . 823 [RFC5535] Bagnulo, M., "Hash-Based Addresses (HBA)", RFC 5535, 824 DOI 10.17487/RFC5535, June 2009, 825 . 827 [RFC7217] Gont, F., "A Method for Generating Semantically Opaque 828 Interface Identifiers with IPv6 Stateless Address 829 Autoconfiguration (SLAAC)", RFC 7217, 830 DOI 10.17487/RFC7217, April 2014, 831 . 833 [RFC8036] Cam-Winget, N., Ed., Hui, J., and D. Popa, "Applicability 834 Statement for the Routing Protocol for Low-Power and Lossy 835 Networks (RPL) in Advanced Metering Infrastructure (AMI) 836 Networks", RFC 8036, DOI 10.17487/RFC8036, January 2017, 837 . 839 [RFC8065] Thaler, D., "Privacy Considerations for IPv6 Adaptation- 840 Layer Mechanisms", RFC 8065, DOI 10.17487/RFC8065, 841 February 2017, . 843 [RFC8066] Chakrabarti, S., Montenegro, G., Droms, R., and J. 844 Woodyatt, "IPv6 over Low-Power Wireless Personal Area 845 Network (6LoWPAN) ESC Dispatch Code Points and 846 Guidelines", RFC 8066, DOI 10.17487/RFC8066, February 847 2017, . 849 Authors' Addresses 851 Jianqiang Hou 852 Huawei Technologies 853 101 Software Avenue, 854 Nanjing 210012 855 China 857 Email: houjianqiang@huawei.com 858 Bing Liu 859 Huawei Technologies 860 No. 156 Beiqing Rd. Haidian District, 861 Beijing 100095 862 China 864 Email: remy.liubing@huawei.com 866 Yong-Geun Hong 867 Electronics and Telecommunications Research Institute 868 161 Gajeong-Dong Yuseung-Gu 869 Daejeon 305-700 870 Korea 872 Email: yghong@etri.re.kr 874 Xiaojun Tang 875 State Grid Electric Power Research Institute 876 19 Chengxin Avenue 877 Nanjing 211106 878 China 880 Email: itc@sgepri.sgcc.com.cn 882 Charles E. Perkins 883 Futurewei 884 2330 Central Expressway 885 Santa Clara 95050 886 United States of America 888 Email: charliep@computer.org