idnits 2.17.1 draft-hou-6lo-plc-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 21, 2018) is 2012 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 312, but not defined == Missing Reference: 'ITU-T G.9905' is mentioned on line 539, 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: April 24, 2019 Y-G. Hong 6 ETRI 7 X. Tang 8 SGEPRI 9 C. Perkins 10 Futurewei 11 October 21, 2018 13 Transmission of IPv6 Packets over PLC Networks 14 draft-hou-6lo-plc-05 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 April 24, 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 . . . . . . . . . . . . . . . . . . . . . . . 5 66 3.1. Protocol Stack . . . . . . . . . . . . . . . . . . . . . 5 67 3.2. Addressing Modes . . . . . . . . . . . . . . . . . . . . 6 68 3.3. Maximum Transmission Unit . . . . . . . . . . . . . . . . 6 69 3.4. Routing Protocol . . . . . . . . . . . . . . . . . . . . 7 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 . . . . . . . . . . . . . . . . . 9 74 4.3.1. Unicast Address Mapping for IEEE 1901.1 . . . . . . . 9 75 4.3.2. Unicast Address Mapping for IEEE 1901.2 and ITU-T 76 G.9903 . . . . . . . . . . . . . . . . . . . . . . . 10 77 4.4. Neighbor Discovery . . . . . . . . . . . . . . . . . . . 10 78 4.5. Header Compression . . . . . . . . . . . . . . . . . . . 11 79 4.6. Fragmentation and Reassembly . . . . . . . . . . . . . . 11 80 4.7. Extension at 6lo Adaptation Layer . . . . . . . . . . . . 12 81 5. Internet Connectivity Scenarios and Topologies . . . . . . . 13 82 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 83 7. Security Consideration . . . . . . . . . . . . . . . . . . . 16 84 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 16 85 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 86 9.1. Normative References . . . . . . . . . . . . . . . . . . 16 87 9.2. Informative References . . . . . . . . . . . . . . . . . 18 88 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19 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 The data acquisition devices in these scenarios share common features 99 such as fixed position, large quantity, low data rate and low power 100 consumption. 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 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 137 Coordinator: A device capable of relaying messages. 139 DAD: Duplicate Address Detection 141 PAN device: An entity follows the PLC standards and implements the 142 protocol stack described in this draft. 144 EV: Electric Vehicle 146 IID: IPv6 Interface Identifier 148 IPHC: IP Header Compression 150 LAN: Local Area Network 152 MSDU: MAC Service Data Unit 154 MTU: Maximum Transmission Unit 156 NBPLC: Narrowband Power Line Communication 158 OFDM: Orthogonal Frequency Division Multiplexing 160 PANC: PAN Coordinator, a coordinator which also acts as the primary 161 controller of a PAN. 163 PLC: Power Line Communication 165 PSDU: PHY Service Data Unit 167 RPL: IPv6 Routing Protocol for Low-Power and Lossy Networks 169 RA: Router Advertisement 171 WAN: Wide Area Network 172 The terminology used in this draft is aligned with IEEE 1901.2 174 +-----------------+---------------------+----------------------+ 175 | IEEE 1901.2 | IEEE 1901.1 | ITU-T G.9903 | 176 +-----------------+---------------------+----------------------+ 177 | PAN Coordinator | Central Coordinator | PAN Coordinator | 178 | | | | 179 | Coordinator | Proxy Coordinator | Full-function device | 180 | | | | 181 | Device | Station | PAN Device | 182 +-----------------+---------------------+----------------------+ 184 Table 1: Terminology Mapping between PLC standards 186 3. Overview of PLC 188 PLC technology enables convenient two-way communications for home 189 users and utility companies to monitor and control electric plugged 190 devices such as electricity meters and street lights. Due to the 191 large range of communication frequencies, PLC is generally classified 192 into two categories: Narrowband PLC (NBPLC) for automation of sensors 193 (which have low frequency band and low power cost), and Broadband PLC 194 (BBPLC) for home and industry networking applications. Various 195 standards have been addressed on the MAC and PHY layers for this 196 communication technology, e.g. BBPLC (1.8-250 MHz) including IEEE 197 1901 and ITU-T G.hn, and NBPLC (3-500 kHz) including ITU-T G.9902 198 (G.hnem), ITU-T G.9903 (G3-PLC) [ITU-T_G.9903], ITU-T G.9904 (PRIME), 199 IEEE 1901.2 [IEEE_1901.2] (combination of G3-PLC and PRIME PLC) and 200 IEEE 1901.2a [IEEE_1901.2a] (an amendment to IEEE 1901.2). Moreover, 201 recently a new PLC standard IEEE 1901.1 [IEEE_1901.1], which aims at 202 the medium frequency band less than 12 MHz, has been published by the 203 IEEE standard for Smart Grid Powerline Communication Working Group 204 (SGPLC WG). IEEE 1901.1 balances the needs for bandwidth versus 205 communication range, and is thus a promising option for 6lo 206 applications. 208 3.1. Protocol Stack 210 The protocol stack for IPv6 over PLC is illustrated in Figure 1. The 211 PLC MAC/PHY layer corresponds to IEEE 1901.1, IEEE 1901.2 or ITU-T 212 G.9903. The 6lo adaptation layer for PLC is illustrated in 213 Section 4. For multihop tree and mesh topologies, a routing protocol 214 is likely to be necessary. The routes can be built in mesh-under 215 mode at layer 2 or in route-over mode at layer 3. 217 +----------------------------------------+ 218 | Application Layer | 219 +----------------------------------------+ 220 | TCP/UDP | 221 +----------------------------------------+ 222 | | 223 | IPv6 | 224 | | 225 +----------------------------------------+ 226 | Adaptation layer for IPv6 over PLC | 227 +----------------------------------------+ 228 | PLC MAC Layer | 229 +----------------------------------------+ 230 | PLC PHY Layer | 231 +----------------------------------------+ 233 Figure 1: PLC Protocol Stack 235 3.2. Addressing Modes 237 Each PLC device has a globally unique long address of 48-bit 238 ([IEEE_1901.1]) or 64-bit ([IEEE_1901.2], [ITU-T_G.9903]) and a short 239 address of 12-bit ([IEEE_1901.1]) or 16-bit ([IEEE_1901.2], 240 [ITU-T_G.9903]). The long address is set by the manufacturer 241 according to the IEEE EUI-48 MAC address or the IEEE EUI-64 address. 242 Each PLC device joins the network by using the long address and 243 communicates with other devices by using the short address after 244 joining the network. 246 3.3. Maximum Transmission Unit 248 The Maximum Transmission Unit (MTU) of the MAC layer determines 249 whether fragmentation and reassembly are needed at the adaptation 250 layer of IPv6 over PLC. IPv6 requires an MTU of 1280 octets or 251 greater; thus for a MAC layer with MTU lower than this limit, 252 fragmentation and reassembly at the adaptation layer are required. 254 The IEEE 1901.1 MAC supports upper layer packets up to 2031 octets. 255 The IEEE 1901.2 MAC layer supports the MTU of 1576 octets (the 256 original value of 1280 bytes was updated in 2015 [IEEE_1901.2a]). 257 Though fragmentation and reassembly are not needed in these two 258 technologies, other 6lo functions like header compression are still 259 applicable and useful, particularly in high-noise communication 260 environments. 262 The MTU for ITU-T G.9903 is 400 octets, insufficient for supporting 263 IPv6's MTU. For this reason, fragmentation and reassembly as per 264 [RFC4944] MUST be enabled for G.9903-based networks. 266 3.4. Routing Protocol 268 Routing protocols suitable for use in PLC networks include: 270 o RPL (Routing Protocol for Low-Power and Lossy Networks) [RFC6550] 271 is a layer 3 routing protocol. AODV-RPL [I-D.ietf-roll-aodv-rpl] 272 updates RPL to include reactive, point-to-point, and asymmetric 273 routing. IEEE 1901.2 specifies Information Elements (IEs) with 274 MAC layer metrics, which can be provided to L3 routing protocol 275 for parent selection. For IPv6-addressable PLC networks, a 276 layer-3 routing protocol such as RPL and/or AODV-RPL SHOULD be 277 supported in the standard. 279 o IEEE 1901.1 supports L2 routing. Each PLC node maintains a L2 280 routing table, in which each route entry comprises the short 281 addresses of the destination and the related next hop. The route 282 entries are built during the network establishment via a pair of 283 association request/confirmation messages. The route entries can 284 be changed via a pair of proxy change request/confirmation 285 messages. These association and proxy change messages MUST be 286 approved by the central coordinator. 288 o LOADng is a reactive protocol operating at layer 2 or layer 3. 289 Currently, LOADng is supported in ITU-T G.9903 [ITU-T_G.9903], and 290 the IEEE 1901.2 standard refers to ITU-T G.9903 for LOAD-based 291 networks. 293 4. IPv6 over PLC 295 6LoWPAN standards [RFC4944], [RFC6775], and [RFC6282] provides useful 296 functionality including link-local IPv6 addresses, stateless address 297 auto-configuration, neighbor discovery and header compression. 298 However, due to the different characteristics of the PLC media, the 299 6LoWPAN adaptation layer cannot perfectly fulfill the requirements. 300 Besides, some of the features like fragmentation and reassembly are 301 redudant to some PLC technologies. These considerations suggest the 302 need for a dedicated adaptation layer for PLC, which is detailed in 303 the following subsections. 305 4.1. Stateless Address Autoconfiguration 307 To obtain an IPv6 Interface Identifier (IID), a PLC device performs 308 stateless address autoconfiguration [RFC4944]. The autoconfiguration 309 can be based on either a long or short link-layer address. 311 The IID can be based on the device's 48-bit MAC address or its EUI-64 312 identifier [EUI-64]. A 48-bit MAC address MUST first be extended to 313 a 64-bit Interface ID by inserting 0xFFFE at the fourth and fifth 314 octets as specified in [RFC2464]. The IPv6 IID is derived from the 315 64-bit Interface ID by inverting the U/L bit [RFC4291]. 317 For IEEE 1901.2 and ITU-T G.9903, a 48-bit "pseudo-address" is formed 318 by the 16-bit PAN ID, 16 zero bits and the 16-bit short address. 319 Then, the 64-bit Interface ID MUST be derived by inserting 16-bit 320 0xFFFE into as follows: 322 16_bit_PAN:00FF:FE00:16_bit_short_address 324 For the 12-bit short addresses used by IEEE 1901.1, the 48-bit 325 pseudo-address is formed by 24-bit NID (Network IDentifier, YYYYYY), 326 12 zero bits and a 12-bit TEI (Terminal Equipment Identifier, XXX). 327 The 64-bit Interface ID MUST be derived by inserting 16-bit 0xFFFE 328 into this 48-bit pseudo-address as follows: 330 YYYY:YYFF:FE00:0XXX 332 Since the derived Interface ID is not global, the "Universal/Local" 333 (U/L) bit (7th bit) and the Individual/Group bit (8th bit) MUST both 334 be set to zero. In order to avoid any ambiguity in the derived 335 Interface ID, these two bits MUST NOT be used to generate the PANID 336 (for IEEE 1901.2 and ITU-T G.9903) or NID (for IEEE 1901.1). In 337 other words, the PANID or NID MUST always be chosen so that these 338 bits are zeros. 340 For privacy reasons, the IID derived by the MAC address SHOULD only 341 be used for link-local address configuration. A PLC host SHOULD use 342 the IID derived by the link-layer short address to configure the IPv6 343 address used for communication with the public network; otherwise, 344 the host's MAC address is exposed. 346 4.2. IPv6 Link Local Address 348 The IPv6 link-local address [RFC4291] for a PLC interface is formed 349 by appending the IID, as defined above, to the prefix FE80::/64 (see 350 Figure 2). 352 10 bits 54 bits 64 bits 353 +----------+-----------------------+----------------------------+ 354 |1111111010| (zeros) | Interface Identifier | 355 +----------+-----------------------+----------------------------+ 357 Figure 2: IPv6 Link Local Address for a PLC interface 359 4.3. Unicast Address Mapping 361 The address resolution procedure for mapping IPv6 unicast addresses 362 into PLC link-layer addresses follows the general description in 363 section 7.2 of [RFC4861]. [RFC6775] improves this procedure by 364 eliminating usage of multicast NS. The resolution is realized by the 365 NCEs (neighbor cache entry) created during the address registration 366 at the routers. 6775-update further improves the registration 367 procedure by enabling multiple LLNs to form an IPv6 subnet, and by 368 inserting a link-local address registration to better serve proxy 369 registration of new devices. 371 4.3.1. Unicast Address Mapping for IEEE 1901.1 373 The Source/Target Link-layer Address options for IEEE_1901.1 used in 374 the Neighbor Solicitation and Neighbor Advertisement have the 375 following form. 377 0 1 2 3 378 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 379 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 380 | Type | Length=1 | NID : 381 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 382 :NID (continued)| Padding (all zeros) | TEI | 383 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 385 Figure 3: Unicast Address Mapping for IEEE 1901.1 387 Option fields: 389 Type: 1 for Source Link-layer Address and 2 for Target Link-layer 390 Address. 392 Length: The length of this option (including type and length fields) 393 in units of 8 octets. The value of this field is 1 for the 394 12-bit IEEE 1901.1 PLC short addresses. 396 NID: 24-bit Network IDentifier 398 Padding: 12 zero bits 400 TEI: 12-bit Terminal Equipment Identifier 402 In order to avoid the possibility of duplicated IPv6 addresses, the 403 value of the NID MUST be chosen so that the 7th and 8th bits of the 404 first byte of the NID are both zero. 406 4.3.2. Unicast Address Mapping for IEEE 1901.2 and ITU-T G.9903 408 The Source/Target Link-layer Address options for IEEE_1901.2 and 409 ITU-T G.9903 used in the Neighbor Solicitation and Neighbor 410 Advertisement have the following form. 412 0 1 2 3 413 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 414 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 415 | Type | Length=1 | PAN ID | 416 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 417 | Padding (all zeros) | Short Address | 418 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 420 Figure 4: Unicast Address Mapping for IEEE 1901.2 422 Option fields: 424 Type: 1 for Source Link-layer Address and 2 for Target Link-layer 425 Address. 427 Length: The length of this option (including type and length fields) 428 in units of 8 octets. The value of this field is 1 for the 429 16-bit IEEE 1901.2 PLC short addresses. 431 PAN ID: 16-bit PAN IDentifier 433 Padding: 16 zero bits 435 Short Address: 16-bit short address 437 In order to avoid the possibility of duplicated IPv6 addresses, the 438 value of the PAN ID MUST be chosen so that the 7th and 8th bits of 439 the first byte of the PAN ID are both zero. 441 4.4. Neighbor Discovery 443 Neighbor discovery procedures for 6LoWPAN networks are described in 444 Neighbor Discovery Optimization for 6LoWPANs [RFC6775] and 445 [I-D.ietf-6lo-rfc6775-update]. These optimizations support the 446 registration of sleeping hosts. Although PLC devices are 447 electrically powered, sleeping mode SHOULD still be used for power 448 saving. 450 For IPv6 address prefix dissemination, Router Solicitations (RS) and 451 Router Advertisements (RA) MAY be used as per [RFC6775]. If the PLC 452 network uses route-over mesh, the IPv6 prefix MAY be disseminated by 453 the layer 3 routing protocol, such as RPL which includes the prefix 454 in the DIO message. In this case, the prefix information option 455 (PIO) MUST NOT be included in the Router Advertisement. 457 For context information dissemination, Router Advertisements (RA) 458 MUST be used as per [RFC6775]. The 6LoWPAN context option (6CO) MUST 459 be included in the RA to disseminate the Context IDs used for prefix 460 compression. 462 For address registration, a PLC host MUST register its address to the 463 router using Neighbor Solicitation and Neighbor Advertisement 464 messages. RFC6775-update PLC devices MUST include the EARO with the 465 'R' flag set when sending Neighbor Solicitations, and process 466 Neighbor Advertisements that include EARO to extract status 467 information. If DHCPv6 is used to assign addresses, or the IPv6 468 address is derived by unique long or short link layer address, 469 Duplicate Address Detection (DAD) MUST NOT be utilized. Otherwise, 470 DAD MUST be performed: RFC6775-only PLC devices MUST perform multihop 471 DAD against a 6LBR by using DAR and DAC messages, while for 472 RFC6775-update devices, DAD is proxied by a routing registrar, which 473 MAY operate according to Optimistic DAD (ODAD) [RFC4429]. 475 The mesh-under ITU-T G.9903 network SHOULD NOT utilize the address 476 registration as described in [RFC6775]. ITU-T G.9903 PLC networks 477 MUST use the 6LoWPAN Context Option (6CO) specified in [RFC6775] (see 478 clause 9.4.1.1 in [ITU-T_G.9903]), which can be attached in Router 479 Advertisements to disseminate Context IDs (CIDs) to use for 480 compressing prefixes. 482 4.5. Header Compression 484 The compression of IPv6 datagrams within PLC MAC frames refers to 485 [RFC6282], which updates [RFC4944]. Header compression as defined in 486 [RFC6282] which specifies the compression format for IPv6 datagrams 487 on top of IEEE 802.15.4, is included in this document as the basis 488 for IPv6 header compression in PLC. For situations when PLC MAC MTU 489 cannot support the 1280-octet IPv6 packet, headers MUST be compressed 490 according to [RFC6282] encoding formats. 492 4.6. Fragmentation and Reassembly 494 PLC differs from other wired technologies in that the communication 495 medium is not shielded; thus, to successfully transmit data through 496 power lines, PLC Data Link layer provides the function of 497 segmentation and reassembly. A Segment Control Field is defined in 498 the MAC frame header regardless of whether segmentation is required. 499 The number of data octets of the PHY payload can change dynamically 500 based on channel conditions, thus the MAC payload segmentation in the 501 MAC sublayer is enabled and guarantees a reliable one-hop data 502 transmission. Fragmentation and reassembly is still required at the 503 adaptation layer, if the MAC layer cannot support the minimum MTU 504 demanded by IPv6, which is 1280 octets. 506 In IEEE 1901.1 and IEEE 1901.2, since the MAC layer supports payloads 507 of 2031 octets and 1576 octets respectively, fragmentation is not 508 needed for IPv6 packet transmission. The fragmentation and 509 reassembly defined in [RFC4944] SHOULD NOT be used in the 6lo 510 adaptation layer of IEEE 1901.2. 512 In ITU-T G.9903, the maximum MAC payload size is fixed to 400 octets, 513 so to cope with the required MTU of 1280 octets by IPv6, 514 fragmentation and reassembly at 6lo adaptation layer MUST be provided 515 referring to [RFC4944]. 517 4.7. Extension at 6lo Adaptation Layer 519 Apart from the Dispatch and LOWPAN_IPHC headers specified in 520 [RFC4944], an additional Command Frame Header is needed for the mesh 521 routing procedure in LOADng protocol. Figure 5 illustrates the 522 format of the Command Frame Header [RFC8066]. The ESC dispatch type 523 (01000000b) indicates an ESC extension type follows (see [RFC4944] 524 and [RFC6282]). Then this 1-octet dispatch field is used as the 525 Command Frame Header and filled with the Command ID. The Command ID 526 can be classified into 4 types: 528 o LOADng message (0x01) 530 o LoWPAN bootstrapping protocol message (0x02) 532 o Reserved by ITU-T (0x03-0x0F) 534 o CMSR protocol messages (0X10-0X1F) 536 The LOADng message is used to provide the default routing protocol 537 LOADng while the LoWPAN bootstrapping protocol message is for the 538 LoWPAN bootstrap procedure. The CMSR protocol messages are specified 539 for the Centralized metric-based source routing [ITU-T G.9905] which 540 is out of the scope of this draft. 542 0 1 2 3 543 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 544 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 545 | ESC | Command ID | Command Payload 546 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 548 Figure 5: Command Frame Header Format of ITU-T G.9903 550 Command Frame Header appears in the last position if more than one 551 header is present in the 6LoWPAN frame [ITU-T_G.9903]. On the other 552 hand, this Command Frame Header MUST appear before the LoWPAN_IPHC 553 dispatch type as per[RFC8066]. 555 o Regarding the order of the command frame header, the inconsistency 556 between G.9903 and RFC8066 still exists and is being solved in 557 ITU-T SG15/Q15. 559 Following these two requirements of header order mentioned above, an 560 example of the header order is illustrated in Figure 6 including the 561 Fragmentation type, Fragmentation header, ESC dispatch type, ESC 562 Extension Type (Command ID), ESC Dispatch Payload (Command Payload), 563 LOWPAN_IPHC Dispatch Type, LOWPAN_IPHC header, and Payload. 565 +-----+-----+-----+-----+-----+--------+---------------+------+ 566 |F typ|F hdr| ESC | EET | EDP |Dispatch|LOWPAN_IPHC hdr| Payld| 567 +-----+-----+-----+-----+-----+--------+---------------+------+ 569 Figure 6: A 6LoWPAN packet including the Command Frame Header 571 5. Internet Connectivity Scenarios and Topologies 573 The network model can be simplified to two kinds of network devices: 574 PAN Coordinator (PANC) and PAN Device. The PANC is the primary 575 coordinator of the PLC subnet and can be seen as a master node; PAN 576 Devices are typically PLC meters and sensors. The PANC also serves 577 as the Routing Registrar for proxy registration and DAD procedures, 578 making use of the updated registration procedures in 579 [I-D.ietf-6lo-rfc6775-update]. IPv6 over PLC networks are built as 580 tree, mesh or star according to the use cases. Every network 581 requires at least one PANC to communicate with each PAN Device. Note 582 that the PLC topologies in this section are based on logical 583 connectivity, not physical links. 585 The star topology is common in current PLC scenarios. In single-hop 586 star topologies, communication at the link layer only takes place 587 between a PAN Device and a PANC. The PANC typically collects data 588 (e.g. a meter reading) from the PAN devices, and then concentrates 589 and uploads the data through Ethernet or LPWAN (see Figure 7). The 590 collected data is transmitted by the smart meters through PLC, 591 aggregated by a concentrator, sent to the utility and then to a Meter 592 Data Management System for data storage, analysis and billing. This 593 topology has been widely applied in the deployment of smart meters, 594 especially in apartment buildings. 596 PAN Device PAN Device 597 \ / +--------- 598 \ / / 599 \ / + 600 \ / | 601 PAN Device ------ PANC ===========+ Internet 602 / \ | 603 / \ + 604 / \ \ 605 / \ +--------- 606 PAN Device PAN Device 608 <----------------------> 609 PLC subnet (IPv6 over PLC) 611 Figure 7: PLC Star Network connected to the Internet 613 A tree topology is useful when the distance between a device A and 614 PANC is beyond the PLC allowed limit and there is another device B in 615 between able to communicate with both sides. Device B in this case 616 acts both as a PAN Device and a Coordinator. For this scenario, the 617 link layer communications take place between device A and device B, 618 and between device B and PANC. An example of PLC tree network is 619 depicted in Figure 8. This topology can be applied in the smart 620 street lighting, where the lights adjust the brightness to reduce 621 energy consumption while sensors are deployed on the street lights to 622 provide information such as light intensity, temperature, humidity. 623 Data transmission distance in the street lighting scenario is 624 normally above several kilometers thus the PLC tree network is 625 required. A more sophisticated AMI network may also be constructed 626 into the tree topology which is depicted in [RFC8036]. A tree 627 topology is suitable for AMI scenarios that require large coverage 628 but low density, e.g. the deployment of smart meters in rural areas. 629 RPL is suitable for maintenance of a tree topology in which there is 630 no need for communication directly between PAN devices. 632 PAN Device 633 \ +--------- 634 PAN Device \ / 635 \ \ + 636 \ \ | 637 PAN Device -- PANC ===========+ Internet 638 / / | 639 / / + 640 PAN Device---PAN Device / \ 641 / +--------- 642 PAN Device---PAN Device 644 <-------------------------> 645 PLC subnet (IPv6 over PLC) 647 Figure 8: PLC Tree Network connected to the Internet 649 Mesh networking in PLC is of great potential applications and has 650 been studied for several years. By connecting all nodes with their 651 neighbors in communication range (see Figure 9), mesh topology 652 dramatically enhances the communication efficiency and thus expands 653 the size of PLC networks. A simple use case is the smart home 654 scenario where the ON/OFF state of air conditioning is controlled by 655 the state of home lights (ON/OFF) and doors (OPEN/CLOSE). AODV-RPL 656 enables direct PAN device to PAN device communication, without being 657 obliged to transmit frames through the PANC, which is a requirement 658 often cited for AMI infrastructure. 660 PAN Device---PAN Device 661 / \ / \ +--------- 662 / \ / \ / 663 / \ / \ + 664 / \ / \ | 665 PAN Device--PAN Device---PANC ===========+ Internet 666 \ / \ / | 667 \ / \ / + 668 \ / \ / \ 669 \ / \ / +--------- 670 PAN Device---PAN Device 672 <-------------------------------> 673 PLC subnet (IPv6 over PLC) 675 Figure 9: PLC Mesh Network connected to the Internet 677 6. IANA Considerations 679 There are no IANA considerations related to this document. 681 7. Security Consideration 683 Due to the high accessibility of power grid, PLC might be susceptible 684 to eavesdropping within its communication coverage, e.g. one 685 apartment tenant may have the chance to monitor the other smart 686 meters in the same apartment building. For security consideration, 687 link layer security is guaranteed in every PLC technology. 689 IP addresses may be used to track devices on the Internet; such 690 devices can in turn be linked to individuals and their activities. 691 Depending on the application and the actual use pattern, this may be 692 undesirable. To impede tracking, globally unique and non-changing 693 characteristics of IP addresses should be avoided, e.g., by 694 frequently changing the global prefix and avoiding unique link-layer 695 derived IIDs in addresses. [RFC3315], [RFC3972], [RFC4941], 696 [RFC5535], [RFC7217], and [RFC8065] provide valuable information for 697 IID formation with improved privacy, and are RECOMMENDED for IPv6 698 networks. 700 8. Acknowledgements 702 We gratefully acknowledge suggestions from the members of the IETF 703 6lo working group. Great thanks to Samita Chakrabarti and Gabriel 704 Montenegro for their feedback and support in connecting the IEEE and 705 ITU-T sides. Authors thank Scott Mansfield, Ralph Droms, Pat Kinney 706 for their guidance in the liaison process. Authors wish to thank 707 Stefano Galli, Thierry Lys, Yizhou Li and Yuefeng Wu for their 708 valuable comments and contributions. 710 9. References 712 9.1. Normative References 714 [I-D.ietf-6lo-rfc6775-update] 715 Thubert, P., Nordmark, E., Chakrabarti, S., and C. 716 Perkins, "Registration Extensions for 6LoWPAN Neighbor 717 Discovery", draft-ietf-6lo-rfc6775-update-21 (work in 718 progress), June 2018. 720 [I-D.ietf-roll-aodv-rpl] 721 Anamalamudi, S., Zhang, M., Perkins, C., Anand, S., and B. 722 Liu, "Asymmetric AODV-P2P-RPL in Low-Power and Lossy 723 Networks (LLNs)", draft-ietf-roll-aodv-rpl-05 (work in 724 progress), October 2018. 726 [IEEE_1901.1] 727 IEEE-SA Standards Board, "Standard for Medium Frequency 728 (less than 15 MHz) Power Line Communications for Smart 729 Grid Applications", IEEE 1901.1, May 2018, 730 . 732 [IEEE_1901.2] 733 IEEE-SA Standards Board, "IEEE Standard for Low-Frequency 734 (less than 500 kHz) Narrowband Power Line Communications 735 for Smart Grid Applications", IEEE 1901.2, October 2013, 736 . 739 [ITU-T_G.9903] 740 International Telecommunication Union, "Narrowband 741 orthogonal frequency division multiplexing power line 742 communication transceivers for G3-PLC networks", 743 ITU-T G.9903, February 2014, 744 . 746 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 747 Requirement Levels", BCP 14, RFC 2119, 748 DOI 10.17487/RFC2119, March 1997, 749 . 751 [RFC2464] Crawford, M., "Transmission of IPv6 Packets over Ethernet 752 Networks", RFC 2464, DOI 10.17487/RFC2464, December 1998, 753 . 755 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 756 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 757 DOI 10.17487/RFC4861, September 2007, 758 . 760 [RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler, 761 "Transmission of IPv6 Packets over IEEE 802.15.4 762 Networks", RFC 4944, DOI 10.17487/RFC4944, September 2007, 763 . 765 [RFC6282] Hui, J., Ed. and P. Thubert, "Compression Format for IPv6 766 Datagrams over IEEE 802.15.4-Based Networks", RFC 6282, 767 DOI 10.17487/RFC6282, September 2011, 768 . 770 [RFC6550] Winter, T., Ed., Thubert, P., Ed., Brandt, A., Hui, J., 771 Kelsey, R., Levis, P., Pister, K., Struik, R., Vasseur, 772 JP., and R. Alexander, "RPL: IPv6 Routing Protocol for 773 Low-Power and Lossy Networks", RFC 6550, 774 DOI 10.17487/RFC6550, March 2012, 775 . 777 [RFC6775] Shelby, Z., Ed., Chakrabarti, S., Nordmark, E., and C. 778 Bormann, "Neighbor Discovery Optimization for IPv6 over 779 Low-Power Wireless Personal Area Networks (6LoWPANs)", 780 RFC 6775, DOI 10.17487/RFC6775, November 2012, 781 . 783 9.2. Informative References 785 [I-D.popa-6lo-6loplc-ipv6-over-ieee19012-networks] 786 Popa, D. and J. Hui, "6LoPLC: Transmission of IPv6 Packets 787 over IEEE 1901.2 Narrowband Powerline Communication 788 Networks", draft-popa-6lo-6loplc-ipv6-over- 789 ieee19012-networks-00 (work in progress), March 2014. 791 [IEEE_1901.2a] 792 IEEE-SA Standards Board, "IEEE Standard for Low-Frequency 793 (less than 500 kHz) Narrowband Power Line Communications 794 for Smart Grid Applications - Amendment 1", IEEE 1901.2a, 795 September 2015, . 798 [RFC3315] Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins, 799 C., and M. Carney, "Dynamic Host Configuration Protocol 800 for IPv6 (DHCPv6)", RFC 3315, DOI 10.17487/RFC3315, July 801 2003, . 803 [RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)", 804 RFC 3972, DOI 10.17487/RFC3972, March 2005, 805 . 807 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 808 Architecture", RFC 4291, DOI 10.17487/RFC4291, February 809 2006, . 811 [RFC4429] Moore, N., "Optimistic Duplicate Address Detection (DAD) 812 for IPv6", RFC 4429, DOI 10.17487/RFC4429, April 2006, 813 . 815 [RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy 816 Extensions for Stateless Address Autoconfiguration in 817 IPv6", RFC 4941, DOI 10.17487/RFC4941, September 2007, 818 . 820 [RFC5535] Bagnulo, M., "Hash-Based Addresses (HBA)", RFC 5535, 821 DOI 10.17487/RFC5535, June 2009, 822 . 824 [RFC7217] Gont, F., "A Method for Generating Semantically Opaque 825 Interface Identifiers with IPv6 Stateless Address 826 Autoconfiguration (SLAAC)", RFC 7217, 827 DOI 10.17487/RFC7217, April 2014, 828 . 830 [RFC8036] Cam-Winget, N., Ed., Hui, J., and D. Popa, "Applicability 831 Statement for the Routing Protocol for Low-Power and Lossy 832 Networks (RPL) in Advanced Metering Infrastructure (AMI) 833 Networks", RFC 8036, DOI 10.17487/RFC8036, January 2017, 834 . 836 [RFC8065] Thaler, D., "Privacy Considerations for IPv6 Adaptation- 837 Layer Mechanisms", RFC 8065, DOI 10.17487/RFC8065, 838 February 2017, . 840 [RFC8066] Chakrabarti, S., Montenegro, G., Droms, R., and J. 841 Woodyatt, "IPv6 over Low-Power Wireless Personal Area 842 Network (6LoWPAN) ESC Dispatch Code Points and 843 Guidelines", RFC 8066, DOI 10.17487/RFC8066, February 844 2017, . 846 Authors' Addresses 848 Jianqiang Hou 849 Huawei Technologies 850 101 Software Avenue, 851 Nanjing 210012 852 China 854 Email: houjianqiang@huawei.com 855 Bing Liu 856 Huawei Technologies 857 No. 156 Beiqing Rd. Haidian District, 858 Beijing 100095 859 China 861 Email: remy.liubing@huawei.com 863 Yong-Geun Hong 864 Electronics and Telecommunications Research Institute 865 161 Gajeong-Dong Yuseung-Gu 866 Daejeon 305-700 867 Korea 869 Email: yghong@etri.re.kr 871 Xiaojun Tang 872 State Grid Electric Power Research Institute 873 19 Chengxin Avenue 874 Nanjing 211106 875 China 877 Email: itc@sgepri.sgcc.com.cn 879 Charles E. Perkins 880 Futurewei 881 2330 Central Expressway 882 Santa Clara 95050 883 United States of America 885 Email: charliep@computer.org