idnits 2.17.1 draft-hou-6lo-plc-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 1, 2018) is 2127 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 300, but not defined == Missing Reference: 'ITU-T G.9905' is mentioned on line 518, but not defined == Outdated reference: A later version (-18) exists of draft-ietf-roll-aodv-rpl-03 -- 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: January 2, 2019 Y-G. Hong 6 ETRI 7 X. Tang 8 SGEPRI 9 C. Perkins 10 Futurewei 11 July 1, 2018 13 Transmission of IPv6 Packets over PLC Networks 14 draft-hou-6lo-plc-04 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, IEEE 1901.2 and IEEE 27 1901.2a. 29 Status of This Memo 31 This Internet-Draft is submitted in full conformance with the 32 provisions of BCP 78 and BCP 79. 34 Internet-Drafts are working documents of the Internet Engineering 35 Task Force (IETF). Note that other groups may also distribute 36 working documents as Internet-Drafts. The list of current Internet- 37 Drafts is at https://datatracker.ietf.org/drafts/current/. 39 Internet-Drafts are draft documents valid for a maximum of six months 40 and may be updated, replaced, or obsoleted by other documents at any 41 time. It is inappropriate to use Internet-Drafts as reference 42 material or to cite them other than as "work in progress." 44 This Internet-Draft will expire on January 2, 2019. 46 Copyright Notice 48 Copyright (c) 2018 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (https://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with respect 56 to this document. Code Components extracted from this document must 57 include Simplified BSD License text as described in Section 4.e of 58 the Trust Legal Provisions and are provided without warranty as 59 described in the Simplified BSD License. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 64 2. Requirements Notation and Terminology . . . . . . . . . . . . 3 65 3. Overview of PLC . . . . . . . . . . . . . . . . . . . . . . . 4 66 3.1. Protocol Stack . . . . . . . . . . . . . . . . . . . . . 5 67 3.2. Addressing Modes . . . . . . . . . . . . . . . . . . . . 5 68 3.3. Maximum Transmission Unit . . . . . . . . . . . . . . . . 6 69 3.4. Routing Protocol . . . . . . . . . . . . . . . . . . . . 6 70 4. IPv6 over PLC . . . . . . . . . . . . . . . . . . . . . . . . 7 71 4.1. Stateless Address Autoconfiguration . . . . . . . . . . . 7 72 4.2. IPv6 Link Local Address . . . . . . . . . . . . . . . . . 8 73 4.3. Unicast Address Mapping . . . . . . . . . . . . . . . . . 8 74 4.3.1. Unicast Address Mapping for IEEE 1901.1 . . . . . . . 8 75 4.3.2. Unicast Address Mapping for IEEE 1901.2 and ITU-T 76 G.9903 . . . . . . . . . . . . . . . . . . . . . . . 9 77 4.4. Neighbor Discovery . . . . . . . . . . . . . . . . . . . 10 78 4.5. Header Compression . . . . . . . . . . . . . . . . . . . 10 79 4.6. Fragmentation and Reassembly . . . . . . . . . . . . . . 11 80 4.7. Extension at 6lo Adaptation Layer . . . . . . . . . . . . 11 81 5. Internet Connectivity Scenarios and Topologies . . . . . . . 12 82 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 83 7. Security Consideration . . . . . . . . . . . . . . . . . . . 15 84 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 15 85 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 86 9.1. Normative References . . . . . . . . . . . . . . . . . . 15 87 9.2. Informative References . . . . . . . . . . . . . . . . . 17 88 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18 90 1. Introduction 92 The idea of using power lines for both electricity supply and 93 communication can be traced back to the beginning of the last 94 century. With the advantage of existing power grid, Power Line 95 Communication (PLC) is a good candidate for supporting various 96 service scenarios such as in houses and offices, in trains and 97 vehicles, in smart grid and advanced metering infrastructure (AMI). 98 Such applications cover the smart meters for electricity, gas and 99 water that share common features such as fixed position, large 100 quantity, low data rate, and long life time. 102 Although PLC technology has evolved over several decades, it has not 103 been fully adapted for IPv6 based constrained networks. The 6lo 104 related scenarios lie in the low voltage PLC networks with most 105 applications in the area of Advanced Metering Infrastructure (AMI), 106 Vehicle-to-Grid communications, in-home energy management and smart 107 street lighting. IPv6 is important for PLC networks, due to its 108 large address space and efficent address auto-configuration. A 109 comparison among various existing PLC standards is provided to 110 facilitate the selection of the most applicable standard in 111 particular scenarios. 113 The following sections provide a brief overview of PLC, then describe 114 transmission of IPv6 packets over PLC networks. The general approach 115 is to adapt elements of the 6LoWPAN specifications [RFC4944], 116 [RFC6282], and [RFC6775] to 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: 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 137 DAD: Duplicate Address Detection 139 EV: Electric Vehicle 141 HDPLC: High Definition Power Line Communication 143 IID: IPv6 Interface Identifier 145 IPHC: IP Header Compression 147 LAN: Local Area Network 149 LOADng: Lightweight On-demand Ad-hoc Distance-vector Routing 150 Protocol Next Generation 152 MSDU: MAC Service Data Unit 154 MTU: Maximum Transmission Unit 156 NBPLC: Narrowband Power Line Communication 158 OFDM: Orthogonal Frequency Division Multiplexing 160 PCO: PAN Coordinator 162 PLC: Power Line Communication 164 PSDU: PHY Service Data Unit 166 RPL: IPv6 Routing Protocol for Low-Power and Lossy Networks 168 RA: Router Advertisement 170 WAN: Wide Area Network 172 3. Overview of PLC 174 PLC technology enables convenient two-way communications for home 175 users and utility companies to monitor and control electric plugged 176 devices such as electricity meters and street lights. Due to the 177 large range of communication frequencies, PLC is generally classified 178 into two categories: Narrowband PLC (NBPLC) for automation of 179 sensors, and Broadband PLC (BBPLC) for home and industry networking 180 applications. Various standards have been addressed on the MAC and 181 PHY layers for this communication technology, e.g. BBPLC (1.8-250 182 MHz) including IEEE 1901 and ITU-T G.hn, and NBPLC (3-500 kHz) 183 including IEEE 1901.2 [IEEE_1901.2], ITU-T G.9902 (G.hnem), ITU-T 184 G.9903 (G3-PLC) [ITU-T_G.9903] and ITU-T G.9904 (PRIME). And 185 moreover, recently a new PLC standard IEEE 1901.1 [IEEE_1901.1], 186 which aims at the medium frequency band less than 12 MHz, has been 187 published by the IEEE standard for Smart Grid Powerline Communication 188 Working Group (SGPLC WG). 190 Narrowband PLC is an important branch of PLC technology due to its 191 low frequency band and low power cost. So far the recent PLC 192 standards, ITU-T G.9903 (G3-PLC) and IEEE 1901.2, are dominating as 193 two of the most robust schemes available. IEEE 1901.2 is a 194 combination of G3-PLC and PRIME while IEEE 1901.2a [IEEE_1901.2a] is 195 an amendment to IEEE 1901.2. IEEE 1901.1 balances the needs for 196 bandwidth versus communication range, and is thus a promising option 197 for the 6lo applications mentioned above. 199 3.1. Protocol Stack 201 The protocol stack for IPv6 over PLC is illustrated in Figure 1. The 202 PLC MAC/PHY layer corresponds to IEEE 1901.1, IEEE 1901.2 or ITU-T 203 G.9903. The 6lo adaptation layer for PLC is illustrated in 204 Section 4. A routing protocol (e.g., RPL [RFC6550] or AODV-RPL 205 [I-D.ietf-roll-aodv-rpl]) at the Network layer is optional according 206 to the IEEE 1901.1 and IEEE 1901.2 PLC standards mentioned in this 207 document. 209 +----------------------------------------+ 210 | Application Layer | 211 +----------------------------------------+ 212 | TCP/UDP | 213 +----------------------------------------+ 214 | | 215 | IPv6 | 216 | | 217 +----------------------------------------+ 218 | Adaptation layer for IPv6 over PLC | 219 +----------------------------------------+ 220 | PLC MAC Layer | 221 +----------------------------------------+ 222 | PLC PHY Layer | 223 +----------------------------------------+ 225 Figure 1: PLC Protocol Stack 227 3.2. Addressing Modes 229 Each PLC device has a globally unique long address of 48-bit 230 ([IEEE_1901.1]) or 64-bit ([IEEE_1901.2], [ITU-T_G.9903]) and a short 231 address of 12-bit ([IEEE_1901.1]) or 16-bit ([IEEE_1901.2], 232 [ITU-T_G.9903]). The long address is set by the manufacturer 233 according to the IEEE EUI-48 MAC address or the IEEE EUI-64 address. 234 Each PLC device joins the network by using the long address and 235 communicates with other devices by using the short address after 236 joining the network. 238 3.3. Maximum Transmission Unit 240 The Maximum Transmission Unit (MTU) of the MAC layer determines 241 whether fragmentation and reassembly are needed at the adaptation 242 layer of IPv6 over PLC. IPv6 requires an MTU of 1280 octets or 243 greater; thus for a MAC layer with MTU lower than this limit, 244 fragmentation and reassembly at the adaptation layer are required. 246 The IEEE 1901.1 MAC supports upper layer packets up to 2031 octets. 247 The IEEE 1901.2 MAC layer supports the MTU of 1576 octets (the 248 original value of 1280 bytes was updated in 2015 [IEEE_1901.2a]). 249 Though fragmentation and reassembly are not needed in these two 250 technologies, other 6lo functions like header compression are still 251 applicable and useful, particularly in high-noise communication 252 environments. 254 The MTU for ITU-T G.9903 is 400 octets, insufficient for supporting 255 IPv6's MTU. For this reason, fragmentation and reassembly as per 256 [RFC4944] MUST be enabled for G.9903-based networks. 258 3.4. Routing Protocol 260 Routing algorithms suitable for use in PLC networks for AMI 261 applications include: 263 o RPL (Routing Protocol for Low-Power and Lossy Networks) [RFC6550] 264 is a routing protocol (operating at layer 3). AODV-RPL augments 265 RPL to include reactive, point-to-point, and asymmetric routing. 267 o ITU-T G.9903 [ITU-T_G.9903] uses LOADng which is a reactive 268 protocol, operating in layer 2 or layer 3. 270 o IEEE 1901.1 supports L2 routing, in which the routing entries are 271 built using short addresses. 273 IEEE 1901.2 specifies additional Information Elements (IEs), with 274 user-defined content, to supply PHY layer metrics for the IP layer. 275 These IEs enable routing protocols to be used in 1901.2 networks. 276 For IPv6-addressable PLC networks, a layer-3 routing protocol such as 277 RPL and/or AODV-RPL SHOULD be supported in the standard. Currently, 278 LOADng is supported in ITU-T G.9903, and the IEEE 1901.2 standard 279 refers to ITU-T G.9903 for LOAD-based networks. 281 4. IPv6 over PLC 283 6LoWPAN standards [RFC4944], [RFC6775], and [RFC6282] provides useful 284 functionality including link-local IPv6 addresses, stateless address 285 auto-configuration, neighbor discovery and header compression. 286 However, due to the different characteristics of the PLC media, the 287 6LoWPAN adaptation layer cannot perfectly fulfill the requirements. 288 Besides, some of the features like fragmentation and reassembly are 289 redudant to some PLC technologies. Therefore, it is necessary to 290 have a dedicated adaptation layer for PLC, which is detailed in the 291 following subsections. 293 4.1. Stateless Address Autoconfiguration 295 To obtain an IPv6 Interface Identifier (IID), a PLC device performs 296 stateless address autoconfiguration [RFC4944]. The autoconfiguration 297 can be based on either a long or short link-layer address. 299 The IID can be based on the device's 48-bit MAC address or its EUI-64 300 identifier [EUI-64]. A 48-bit MAC address MUST first be extended to 301 a 64-bit Interface ID by inserting 0xFFFE at the fourth and fifth 302 octets as specified in [RFC2464]. The IPv6 IID is derived from the 303 64-bit Interface ID by inverting the U/L bit [RFC4291]. 305 For IEEE 1901.2 and ITU-T G.9903, a 48-bit "pseudo-address" is formed 306 by the 16-bit PAN ID, 16 zero bits and the 16-bit short address. 307 Then, the 64-bit Interface ID MUST be derived by inserting 16-bit 308 0xFFFE into as follows: 310 16_bit_PAN:00FF:FE00:16_bit_short_address 312 For the 12-bit short addresses used by IEEE 1901.1, the 48-bit 313 pseudo-address is formed by 24-bit NID (Network IDentifier, YYYYYY), 314 12 zero bits and a 12-bit TEI (Terminal Equipment Identifier, XXX). 315 The 64-bit Interface ID MUST be derived by inserting 16-bit 0xFFFE 316 into this 48-bit pseudo-address as follows: 318 YYYY:YYFF:FE00:0XXX 320 Since the derived Interface ID is not global, the "Universal/Local" 321 (U/L) bit (7th bit) and the Individual/Group bit (8th bit) MUST both 322 be set to zero. In order to avoid any ambiguity in the derived 323 Interface ID, these two bits MUST NOT be used to generate the PANID 324 (for IEEE 1901.2 and ITU-T G.9903) or NID (for IEEE 1901.1). In 325 other words, the PANID or NID MUST always be chosen so that these 326 bits are zeros. 328 4.2. IPv6 Link Local Address 330 The IPv6 link-local address [RFC4291] for a PLC interface is formed 331 by appending the IID, as defined above, to the prefix FE80::/64 (see 332 Figure 2). 334 10 bits 54 bits 64 bits 335 +----------+-----------------------+----------------------------+ 336 |1111111010| (zeros) | Interface Identifier | 337 +----------+-----------------------+----------------------------+ 339 Figure 2: IPv6 Link Local Address for a PLC interface 341 4.3. Unicast Address Mapping 343 The address resolution procedure for mapping IPv6 unicast addresses 344 into PLC link-layer addresses follows the general description in 345 section 7.2 of [RFC4861]. [RFC6775] improves this procedure by 346 eliminating usage of multicast NS. The resolution is realized by the 347 NCEs (neighbor cache entry) created during the address registration 348 at the routers. 6775-update further improves the registration 349 procedure by enabling multiple LLNs to form an IPv6 subnet, and by 350 inserting a link-local address registration to better serve proxy 351 registration of new devices. 353 4.3.1. Unicast Address Mapping for IEEE 1901.1 355 The Source/Target Link-layer Address options for IEEE_1901.1 used in 356 the Neighbor Solicitation and Neighbor Advertisement have the 357 following form. 359 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 360 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 361 | Type | Length=1 | NID : 362 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 363 :NID (continued)| Padding (all zeros) | TEI | 364 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 366 Figure 3: Unicast Address Mapping for IEEE 1901.1 368 Option fields: 370 Type: 1 for Source Link-layer Address and 2 for Target Link-layer 371 Address. 373 Length: The length of this option (including type and length fields) 374 in units of 8 octets. The value of this field is 1 for the 375 12-bit IEEE 1901.1 PLC short addresses. 377 NID: 24-bit Network IDentifier 379 Padding: 12 zero bits 381 TEI: 12-bit Terminal Equipment Identifier 383 In order to avoid the possibility of duplicated IPv6 addresses, the 384 value of the NID MUST be chosen so that the 7th and 8th bits of the 385 first byte of the NID are both zero. 387 4.3.2. Unicast Address Mapping for IEEE 1901.2 and ITU-T G.9903 389 The Source/Target Link-layer Address options for IEEE_1901.2 and 390 ITU-T G.9903 used in the Neighbor Solicitation and Neighbor 391 Advertisement have the following form. 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 | PAN ID | 396 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 397 | Padding (all zeros) | Short Address | 398 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 400 Figure 4: Unicast Address Mapping for IEEE 1901.2 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 16-bit IEEE 1901.2 PLC short addresses. 411 PAN ID: 16-bit PAN IDentifier 413 Padding: 16 zero bits 415 Short Address: 16-bit short address 417 In order to avoid the possibility of duplicated IPv6 addresses, the 418 value of the PAN ID MUST be chosen so that the 7th and 8th bits of 419 the first byte of the PAN ID are both zero. 421 4.4. Neighbor Discovery 423 Neighbor discovery procedures for 6LoWPAN networks are described in 424 Neighbor Discovery Optimization for 6LoWPANs [RFC6775] and 425 [I-D.ietf-6lo-rfc6775-update]. These optimizations support the 426 registration of sleeping hosts. Although PLC devices are 427 electrically powered, sleeping mode SHOULD still be used for power 428 saving. 430 RFC6775-only [RFC6775] PLC devices follow Sections 5.3 and 5.4 of 431 that specification for sending Router Solicitations and processing 432 Router Advertisements to acquire the IPv6 prefix and context 433 information. Such a PLC host MUST register its address to the router 434 using Neighbor Solicitation and Neighbor Advertisement messages. In 435 addition, if DHCPv6 is used to assign addresses, or the IPv6 address 436 is derived by unique long or short link layer address, Duplicate 437 Address Detection (DAD) MUST NOT be utilized. 439 RFC6775-update [I-D.ietf-6lo-rfc6775-update] PLC devices include the 440 EARO with the 'R' flag set when sending Router Solicitations, and 441 process Router Advertisements that include EARO to extract status 442 information. Duplicate Address Detection is in this case proxied by 443 a routing registrar, which MAY operate according to Optimistic DAD 444 (ODAD) [RFC4429]. For networks with mixed RFC6775-only and 445 RFC6775-update devices, the RFC6775-update PLC devices MUST use a 446 64-bit ROVR. 448 If the PLC network uses route-over mesh, the IPv6 prefix MAY be 449 disseminated by the layer 3 routing protocol, such as RPL which 450 includes the prefix in the DIO message. The prefix information 451 option (PIO) MUST NOT be included in the Router Advertisement. 453 The mesh-under ITU-T G.9903 network SHOULD NOT utilize the address 454 registration as described in [RFC6775]. ITU-T G.9903 PLC networks 455 MUST use the 6LoWPAN Context Option (6CO) specified in [RFC6775] (see 456 clause 9.4.1.1 in [ITU-T_G.9903]), which can be attached in Router 457 Advertisements to disseminate Context IDs (CIDs) to use for 458 compressing prefixes. An implementation for mesh-under operation 459 MUST use [RFC6775] mechanisms for managing IPv6 prefixes and 460 corresponding header compression context information [RFC6282]. 462 4.5. Header Compression 464 The compression of IPv6 datagrams within PLC MAC frames refers to 465 [RFC6282], which updates [RFC4944]. Header compression as defined in 466 [RFC6282] which specifies the compression format for IPv6 datagrams 467 on top of IEEE 802.15.4, is included in this document as the basis 468 for IPv6 header compression in PLC. For situations when PLC MAC MTU 469 cannot support the 1280-octet IPv6 packet, headers MUST be compressed 470 according to [RFC6282] encoding formats. 472 4.6. Fragmentation and Reassembly 474 PLC differs from other wired technologies in that the communication 475 medium is not shielded; thus, to successfully transmit data through 476 power lines, PLC Data Link layer provides the function of 477 segmentation and reassembly. A Segment Control Field is defined in 478 the MAC frame header regardless of whether segmentation is required. 479 The number of data octets of the PHY payload can change dynamically 480 based on channel conditions, thus the MAC payload segmentation in the 481 MAC sublayer is enabled and guarantees a reliable one-hop data 482 transmission. 484 In IEEE 1901.1 and IEEE 1901.2, since the MAC layer supports a 485 payload of respectively 2031 octets and 1576 octets, which is larger 486 than the minimum MTU required by IPv6 packets, there is no need of 487 fragmentation for the IPv6 packet transmission, thus the 488 fragmentation and reassembly defined in [RFC4944] MUST NOT be used in 489 the 6lo adaptation layer of IEEE 1901.2. 491 In ITU-T G.9903, the maximum MAC payload size is fixed to 400 octets, 492 so to cope with the required MTU of 1280 octets by IPv6, 493 fragmentation and reassembly at 6lo adaptation layer MUST be provided 494 referring to [RFC4944]. 496 4.7. Extension at 6lo Adaptation Layer 498 Apart from the Dispatch and LOWPAN_IPHC headers specified in 499 [RFC4944], an additional Command Frame Header is needed for the mesh 500 routing procedure in LOADng protocol. Figure 5 illustrates the 501 format of the Command Frame Header [RFC8066]. The ESC dispatch type 502 (01000000b) indicates an ESC extension type follows (see [RFC4944] 503 and [RFC6282]). Then this 1-octet dispatch field is used as the 504 Command Frame Header and filled with the Command ID. The Command ID 505 can be classified into 4 types: 507 o LOADng message (0x01) 509 o LoWPAN bootstrapping protocol message (0x02) 511 o Reserved by ITU-T (0x03-0x0F) 513 o CMSR protocol messages (0X10-0X1F) 515 The LOADng message is used to provide the default routing protocol 516 LOADng while the LoWPAN bootstrapping protocol message is for the 517 LoWPAN bootstrap procedure. The CMSR protocol messages are specified 518 for the Centralized metric-based source routing [ITU-T G.9905] which 519 is out of the scope of this draft. 521 0 1 2 3 522 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 523 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 524 | ESC | Command ID | Command Payload 525 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 527 Figure 5: Command Frame Header Format of ITU-T G.9903 529 Command Frame Header appears in the last position if more than one 530 header is present in the 6LoWPAN frame [ITU-T_G.9903]. On the other 531 hand, this Command Frame Header MUST appear before the LoWPAN_IPHC 532 dispatch type as per[RFC8066]. 534 o Regarding the order of the command frame header, the inconsistency 535 between G.9903 and RFC8066 still exists and is being solved in 536 ITU-T SG15/Q15. 538 Following these two requirements of header order mentioned above, an 539 example of the header order is illustrated in Figure 6 including the 540 Fragmentation type, Fragmentation header, ESC dispatch type, ESC 541 Extension Type (Command ID), ESC Dispatch Payload (Command Payload), 542 LOWPAN_IPHC Dispatch Type, LOWPAN_IPHC header, and Payload. 544 +-----+-----+-----+-----+-----+--------+---------------+------+ 545 |F typ|F hdr| ESC | EET | EDP |Dispatch|LOWPAN_IPHC hdr| Payld| 546 +-----+-----+-----+-----+-----+--------+---------------+------+ 548 Figure 6: A 6LoWPAN packet including the Command Frame Header 550 5. Internet Connectivity Scenarios and Topologies 552 The network model can be simplified to two kinds of network devices: 553 PAN Coordinator (PCO) and PAN Device. The PCO is the coordinator of 554 the PLC subnet and can be seen as a master node; PAN Devices are 555 typically PLC meters and sensors. The PCO also serves as the Routing 556 Registrar for proxy registration and DAD procedures, making use of 557 the updated registration procedures in [I-D.ietf-6lo-rfc6775-update]. 558 IPv6 over PLC networks are built as tree, mesh or star according to 559 the use cases. Every network requires at least one PCO to 560 communicate with each PAN Device. Note that the PLC topologies in 561 this section are based on logical connectivity, not physical links. 563 The star topology is common in current PLC scenarios. In star 564 topologies, communication at the link layer only takes place between 565 a PAN Device and a PCO. The PCO typically collects data (e.g. smart 566 meter reading) from the PAN devices, and then concentrates and 567 uploads the data through Ethernet or LPWAN (see Figure 7). The 568 collected data is transmitted by the smart meters through PLC, 569 aggregated by a concentrator, sent to the utility and then to a Meter 570 Data Management System for data storage, analysis and billing. This 571 topology has been widely applied in the deployment of smart meters, 572 especially in apartment buildings. 574 PAN Device PAN Device 575 \ / +--------- 576 \ / / 577 \ / + 578 \ / | 579 PAN Device ------ PCO ===========+ Internet 580 / \ | 581 / \ + 582 / \ \ 583 / \ +--------- 584 PAN Device PAN Device 586 <----------------------> 587 PLC subnet (IPv6 over PLC) 589 Figure 7: PLC Star Network connected to the Internet 591 A tree topology is useful when the distance between a device A and 592 PCO is beyond the PLC allowed limit and there is another device B in 593 between able to communicate with both sides. Device B in this case 594 acts both as a PAN Device and a Proxy Coordinator. For this 595 scenario, the link layer communications take place between device A 596 and device B, and between device B and PCO. An example of PLC tree 597 network is depicted in Figure 8. This topology can be applied in the 598 smart street lighting, where the lights adjust the brightness to 599 reduce energy consumption while sensors are deployed on the street 600 lights to provide information such as light intensity, temperature, 601 humidity. Data transmission distance in the street lighting scenario 602 is normally above several kilometers thus the PLC tree network is 603 required. A more sophisticated AMI network may also be constructed 604 into the tree topology which is depicted in [RFC8036]. A tree 605 topology is suitable for AMI scenarios that require large coverage 606 but low density, e.g. the deployment of smart meters in rural areas. 607 RPL is suitable for maintenance of a tree topology in which there is 608 no need for communication directly between PAN devices. 610 PAN Device 611 \ +--------- 612 PAN Device \ / 613 \ \ + 614 \ \ | 615 PAN Device -- PCO ===========+ Internet 616 / / | 617 / / + 618 PAN Device---PAN Device / \ 619 / +--------- 620 PAN Device---PAN Device 622 <-------------------------> 623 PLC subnet (IPv6 over PLC) 625 Figure 8: PLC Tree Network connected to the Internet 627 Mesh networking in PLC is of great potential applications and has 628 been studied for several years. By connecting all nodes with their 629 neighbors in communication range (see Figure 9), mesh topology 630 dramatically enhances the communication efficiency and thus expands 631 the size of PLC networks. A simple use case is the smart home 632 scenario where the ON/OFF state of air conditioning is controlled by 633 the state of home lights (ON/OFF) and doors (OPEN/CLOSE). AODV-RPL 634 enables direct PAN device to PAN devices (without being obliged to 635 transmit frames through the PCO). This significantly improves 636 performance in typical use cases, like charging station to electric 637 vehicle (EV) communications. 639 PAN Device---PAN Device 640 / \ / \ +--------- 641 / \ / \ / 642 / \ / \ + 643 / \ / \ | 644 PAN Device--PAN Device---PCO ===========+ Internet 645 \ / \ / | 646 \ / \ / + 647 \ / \ / \ 648 \ / \ / +--------- 649 PAN Device---PAN Device 651 <-------------------------------> 652 PLC subnet (IPv6 over PLC) 654 Figure 9: PLC Mesh Network connected to the Internet 656 6. IANA Considerations 658 There are no IANA considerations related to this document. 660 7. Security Consideration 662 Due to the high accessibility of power grid, PLC might be susceptible 663 to eavesdropping within its communication coverage, e.g. one 664 apartment tenant may have the chance to monitor the other smart 665 meters in the same apartment building. For security consideration, 666 link layer security is guaranteed in every PLC technology. 668 IP addresses may be used to track devices on the Internet; such 669 devices can in turn be linked to individuals and their activities. 670 Depending on the application and the actual use pattern, this may be 671 undesirable. To impede tracking, globally unique and non-changing 672 characteristics of IP addresses should be avoided, e.g., by 673 frequently changing the global prefix and avoiding unique link-layer 674 derived IIDs in addresses. [RFC3315], [RFC3972], [RFC4941], 675 [RFC5535], [RFC7217], and [RFC8065] provide valuable information for 676 IID formation with improved privacy, and are RECOMMENDED for IPv6 677 networks. 679 8. Acknowledgements 681 We gratefully acknowledge suggestions from the members of the IETF 682 6lo working group. Great thanks to Samita Chakrabarti and Gabriel 683 Montenegro for their feedback and support in connecting the IEEE and 684 ITU-T sides. Authors thank Scott Mansfield, Ralph Droms, Pat Kinney 685 for their guidance in the liaison process. Authors wish to thank 686 Stefano Galli, Thierry Lys, Yizhou Li and Yuefeng Wu for their 687 valuable comments and contributions. 689 9. References 691 9.1. Normative References 693 [I-D.ietf-6lo-rfc6775-update] 694 Thubert, P., Nordmark, E., Chakrabarti, S., and C. 695 Perkins, "Registration Extensions for 6LoWPAN Neighbor 696 Discovery", draft-ietf-6lo-rfc6775-update-21 (work in 697 progress), June 2018. 699 [I-D.ietf-roll-aodv-rpl] 700 Anamalamudi, S., Zhang, M., Sangi, A., Perkins, C., Anand, 701 S., and B. Liu, "Asymmetric AODV-P2P-RPL in Low-Power and 702 Lossy Networks (LLNs)", draft-ietf-roll-aodv-rpl-03 (work 703 in progress), March 2018. 705 [IEEE_1901.1] 706 IEEE-SA Standards Board, "Standard for Medium Frequency 707 (less than 15 MHz) Power Line Communications for Smart 708 Grid Applications", IEEE 1901.1, May 2018, 709 . 711 [IEEE_1901.2] 712 IEEE-SA Standards Board, "IEEE Standard for Low-Frequency 713 (less than 500 kHz) Narrowband Power Line Communications 714 for Smart Grid Applications", IEEE 1901.2, October 2013, 715 . 718 [ITU-T_G.9903] 719 International Telecommunication Union, "Narrowband 720 orthogonal frequency division multiplexing power line 721 communication transceivers for G3-PLC networks", 722 ITU-T G.9903, February 2014, 723 . 725 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 726 Requirement Levels", BCP 14, RFC 2119, 727 DOI 10.17487/RFC2119, March 1997, 728 . 730 [RFC2464] Crawford, M., "Transmission of IPv6 Packets over Ethernet 731 Networks", RFC 2464, DOI 10.17487/RFC2464, December 1998, 732 . 734 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 735 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 736 DOI 10.17487/RFC4861, September 2007, 737 . 739 [RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler, 740 "Transmission of IPv6 Packets over IEEE 802.15.4 741 Networks", RFC 4944, DOI 10.17487/RFC4944, September 2007, 742 . 744 [RFC6282] Hui, J., Ed. and P. Thubert, "Compression Format for IPv6 745 Datagrams over IEEE 802.15.4-Based Networks", RFC 6282, 746 DOI 10.17487/RFC6282, September 2011, 747 . 749 [RFC6550] Winter, T., Ed., Thubert, P., Ed., Brandt, A., Hui, J., 750 Kelsey, R., Levis, P., Pister, K., Struik, R., Vasseur, 751 JP., and R. Alexander, "RPL: IPv6 Routing Protocol for 752 Low-Power and Lossy Networks", RFC 6550, 753 DOI 10.17487/RFC6550, March 2012, 754 . 756 [RFC6775] Shelby, Z., Ed., Chakrabarti, S., Nordmark, E., and C. 757 Bormann, "Neighbor Discovery Optimization for IPv6 over 758 Low-Power Wireless Personal Area Networks (6LoWPANs)", 759 RFC 6775, DOI 10.17487/RFC6775, November 2012, 760 . 762 9.2. Informative References 764 [I-D.popa-6lo-6loplc-ipv6-over-ieee19012-networks] 765 Popa, D. and J. Hui, "6LoPLC: Transmission of IPv6 Packets 766 over IEEE 1901.2 Narrowband Powerline Communication 767 Networks", draft-popa-6lo-6loplc-ipv6-over- 768 ieee19012-networks-00 (work in progress), March 2014. 770 [IEEE_1901.2a] 771 IEEE-SA Standards Board, "IEEE Standard for Low-Frequency 772 (less than 500 kHz) Narrowband Power Line Communications 773 for Smart Grid Applications - Amendment 1", IEEE 1901.2a, 774 September 2015, . 777 [RFC3315] Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins, 778 C., and M. Carney, "Dynamic Host Configuration Protocol 779 for IPv6 (DHCPv6)", RFC 3315, DOI 10.17487/RFC3315, July 780 2003, . 782 [RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)", 783 RFC 3972, DOI 10.17487/RFC3972, March 2005, 784 . 786 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 787 Architecture", RFC 4291, DOI 10.17487/RFC4291, February 788 2006, . 790 [RFC4429] Moore, N., "Optimistic Duplicate Address Detection (DAD) 791 for IPv6", RFC 4429, DOI 10.17487/RFC4429, April 2006, 792 . 794 [RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy 795 Extensions for Stateless Address Autoconfiguration in 796 IPv6", RFC 4941, DOI 10.17487/RFC4941, September 2007, 797 . 799 [RFC5535] Bagnulo, M., "Hash-Based Addresses (HBA)", RFC 5535, 800 DOI 10.17487/RFC5535, June 2009, 801 . 803 [RFC7217] Gont, F., "A Method for Generating Semantically Opaque 804 Interface Identifiers with IPv6 Stateless Address 805 Autoconfiguration (SLAAC)", RFC 7217, 806 DOI 10.17487/RFC7217, April 2014, 807 . 809 [RFC8036] Cam-Winget, N., Ed., Hui, J., and D. Popa, "Applicability 810 Statement for the Routing Protocol for Low-Power and Lossy 811 Networks (RPL) in Advanced Metering Infrastructure (AMI) 812 Networks", RFC 8036, DOI 10.17487/RFC8036, January 2017, 813 . 815 [RFC8065] Thaler, D., "Privacy Considerations for IPv6 Adaptation- 816 Layer Mechanisms", RFC 8065, DOI 10.17487/RFC8065, 817 February 2017, . 819 [RFC8066] Chakrabarti, S., Montenegro, G., Droms, R., and J. 820 Woodyatt, "IPv6 over Low-Power Wireless Personal Area 821 Network (6LoWPAN) ESC Dispatch Code Points and 822 Guidelines", RFC 8066, DOI 10.17487/RFC8066, February 823 2017, . 825 Authors' Addresses 827 Jianqiang Hou 828 Huawei Technologies 829 101 Software Avenue, 830 Nanjing 210012 831 China 833 Email: houjianqiang@huawei.com 834 Bing Liu 835 Huawei Technologies 836 No. 156 Beiqing Rd. Haidian District, 837 Beijing 100095 838 China 840 Email: remy.liubing@huawei.com 842 Yong-Geun Hong 843 Electronics and Telecommunications Research Institute 844 161 Gajeong-Dong Yuseung-Gu 845 Daejeon 305-700 846 Korea 848 Email: yghong@etri.re.kr 850 Xiaojun Tang 851 State Grid Electric Power Research Institute 852 19 Chengxin Avenue 853 Nanjing 211106 854 China 856 Email: itc@sgepri.sgcc.com.cn 858 Charles E. Perkins 859 Futurewei 860 2330 Central Expressway 861 Santa Clara 95050 862 United States of America 864 Email: charliep@computer.org