idnits 2.17.1 draft-hou-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 == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'SHALL not' in this paragraph: For the Mesh addressing type and header, it is worthy to note that the value of the HopsLeft field SHALL not exceed adpMaxHops. When the originator and final destination devices are neighbors (i.e., the next hop address equals the final destination address and the next hop address is present in the originator's neighbor table), the mesh header shall be omitted in the frame. -- The document date (March 10, 2017) is 2602 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: 'RFC6775' is mentioned on line 116, but not defined == Missing Reference: 'RFC 4944' is mentioned on line 512, but not defined == Missing Reference: 'RFC 6775' is mentioned on line 268, but not defined == Missing Reference: 'RFC 6282' is mentioned on line 647, but not defined == Missing Reference: 'RFC 2464' is mentioned on line 291, but not defined == Missing Reference: 'RFC4291' is mentioned on line 298, but not defined -- Looks like a reference, but probably isn't: '1' on line 466 -- Looks like a reference, but probably isn't: '16' on line 473 -- Looks like a reference, but probably isn't: '15' on line 479 == Unused Reference: 'RFC2464' is defined on line 671, but no explicit reference was found in the text == Unused Reference: 'ITU-T G.9960' is defined on line 710, but no explicit reference was found in the text == Unused Reference: 'ITU-T G.9961' is defined on line 716, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'ITU-T G.9903' Summary: 0 errors (**), 0 flaws (~~), 11 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 6Lo Working Group J. Hou 3 Internet-Draft Huawei Technologies 4 Intended Status: Standards Track Y-G. Hong 5 Expires: September 11, 2017 ETRI 6 X. Tang 7 SGEPRI 8 March 10, 2017 10 Transmission of IPv6 Packets over PLC Networks 11 draft-hou-6lo-plc-00 13 Abstract 15 Power Line Communication (PLC), namely using the electric-power lines 16 for indoor and outdoor communications, has been widely applied to 17 support Advanced Metering Infrastructure (AMI), especially the smart 18 meters for electricity. With the inherent advantage of existing 19 electricity infrastructure, PLC is expanding deployments all over the 20 world, indicating the potential demand of IPv6 for future 21 applications. As part of this technology, Narrowband PLC (NBPLC) is 22 focused on the low-bandwidth and low-power scenarios, including 23 current standards such as IEEE 1901.2 and ITU-T G.9903. This 24 document describes how IPv6 packets are transported over constrained 25 PLC networks. 27 Status of this Memo 29 This Internet-Draft is submitted to IETF in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF). Note that other groups may also distribute 34 working documents as Internet-Drafts. The list of current Internet- 35 Drafts is at http://datatracker.ietf.org/drafts/current/. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 This Internet-Draft will expire on September 11, 2017. 44 Copyright Notice 46 Copyright (c) 2017 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (http://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. Code Components extracted from this document must 55 include Simplified BSD License text as described in Section 4.e of 56 the Trust Legal Provisions and are provided without warranty as 57 described in the Simplified BSD License. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2 62 2. Requirements Notation and Terminology . . . . . . . . . . . . 3 63 3. Overview of PLC . . . . . . . . . . . . . . . . . . . . . . . 4 64 3.1. Protocol Stack . . . . . . . . . . . . . . . . . . . . . . 5 65 3.2. Addressing Modes . . . . . . . . . . . . . . . . . . . . . 5 66 3.3. Maximum Transmission Unit . . . . . . . . . . . . . . . . 6 67 4. Specification of IPv6 over Narrowband PLC . . . . . . . . . . 6 68 4.1. IEEE 1901.2 . . . . . . . . . . . . . . . . . . . . . . . 6 69 4.1.1. Stateless Address Autoconfiguration . . . . . . . . . 6 70 4.1.2. IPv6 Link Local Address . . . . . . . . . . . . . . . 7 71 4.1.3. Unicast and Multicast Address Mapping . . . . . . . . 7 72 4.1.4. Header Compression . . . . . . . . . . . . . . . . . . 8 73 4.1.5. Fragmentation and Reassembly . . . . . . . . . . . . . 9 74 4.2. ITU-T G.9903 . . . . . . . . . . . . . . . . . . . . . . . 9 75 4.2.1. Stateless Address Autoconfiguration . . . . . . . . . 9 76 4.2.2. IPv6 Link Local Address . . . . . . . . . . . . . . . 9 77 4.2.3. Unicast and Multicast Address Mapping . . . . . . . . 10 78 4.2.4. Header Compression . . . . . . . . . . . . . . . . . . 11 79 4.2.5. Fragmentation and Reassembly . . . . . . . . . . . . . 11 80 4.2.6. Extension at 6lo Adaptation Layer . . . . . . . . . . 12 81 5. Internet Connectivity Scenarios and Topologies . . . . . . . . 12 82 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 83 7. Security Consideration . . . . . . . . . . . . . . . . . . . . 14 84 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 85 8.1. Normative References . . . . . . . . . . . . . . . . . . . 15 86 8.2. Informative References . . . . . . . . . . . . . . . . . . 15 87 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 16 88 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16 90 1. Introduction 92 The idea of using power line for both electricity supply and 93 communication can be traced back to the beginning of the last 94 century. With the obvious advantage of existing power grid, PLC is a 95 good candidate for supporting various service scenarios such as in 96 houses and offices, in trains and vehicles, in smart grid and 97 advanced metering infrastructure (AMI). Such applications cover the 98 smart meters for electricity, gas and water that share the common 99 features like fixed position, large quantity, low data rate, and long 100 life time. 102 Although PLC technology has an evolution history of several decades, 103 the adaptation of PLC for IP based constrained networks is not fully 104 developed. The 6lo related scenarios lie in the low voltage PLC 105 networks with most applications in the area of Advanced Metering 106 Infrastructure, Vehicle-to-Grid communications, in-home energy 107 management and smart street lighting. It is of great importance to 108 deploy IPv6 for PLC devices for its large address space and quick 109 addressing. In addition, due to various existing PLC standards, a 110 comparison among them is needed to facilitate the selection of the 111 most applicable PLC standard in certain using 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. Similar 6LoPLC 117 adaptation layer was previously proposed in [draft-popa-6lo-6loplc], 118 however, with the same purpose, this document provides more updated, 119 structured and instructive information for the deployment of IPv6 120 over PLC networks. 122 2. Requirements Notation and Terminology 124 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 125 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 126 "OPTIONAL" in this document are to be interpreted as described in 127 [RFC2119]. 129 Below are the terms used in this document: 131 6LoWPAN: IPv6 over Low-Power Wireless Personal Area Network 133 AMI: Advanced Metering Infrastructure 135 BBPLC: Broadband Power Line Communication 137 BR: Border Router 139 HDPLC: High Definition Power Line Communication 141 IID: Interface Identifier 143 LAN: Local Area Network 144 LOADng: Lightweight On-demand Ad-hoc Distance-vector Routing Protocol 145 Next Generation 147 MSDU: MAC Service Data Unit 149 MTU: Maximum Transmission Unit 151 NBPLC: Narrowband Power Line Communication 153 OFDM: Orthogonal Frequency Division Multiplexing 155 PLC: Power Line Communication 157 PSDU: PHY Service Data Unit 159 RPL: IPv6 Routing Protocol for Low-Power and Lossy Networks 161 WAN: Wide Area Network 163 3. Overview of PLC 165 PLC technology enables convenient two-way communications for home 166 users and utility companies to monitor and control electric plugged 167 devices such as electricity meters and street lights. Due to its 168 large range of communication frequencies, PLC is generally classified 169 into two categories: Narrowband PLC (NBPLC) for automation of 170 sensors, and Broadband PLC (BBPLC) for home and industry networking 171 applications. Various standards have been addressed on the MAC and 172 PHY layers for this communication technology, e.g. IEEE 1901 and ITU- 173 T G.hn for BBPLC (1.8-250 MHz), IEEE 1901.2, ITU-T G.9902 (G.hnem), 174 ITU-T G.9903 (G3-PLC) and ITU-T G.9904 (PRIME) for NBPLC (3-500 kHz) 175 and the recent proposal for the IEEE 1901.1 standard aiming at the 176 frequency band of 2-12 MHz. 178 Narrowband PLC is a very important branch of PLC technology due to 179 its low frequency band and low power cost. So far the recent PLC 180 standards, ITU-T G.9903 (G3-PLC) and IEEE 1901.2, are dominating as 181 two of the most robust schemes available. Different networking 182 methods exist in different NBPLC standards. The formation of a ITU-T 183 G.9903 network is based on a MAC Layer routing protocol called LOADng 184 (Lightweight On-demand Ad-hoc Distance-vector Routing Protocol Next 185 Generation). Different from ITU-T G.9903, IEEE 1901.2 enables a 186 variable structure of the MAC layer which can alternatively apply 187 layer-2 or layer-3 mesh networking. IEEE 1901.2 enables a 188 coexistence mode with ITU-T G.9903 using layer-2 LOADng protocol, and 189 on the other hand it allows the adaptation of layer-3 RPL protocol 190 (IPv6 Routing Protocol for Low-Power and Lossy Networks). 192 The IEEE 1901.1 WG is currently working on a new PLC standard, IEEE 193 1901.1, which focuses on the frequency band of 2-12 MHz [IEEE 194 1901.1]. This promising medium-frequency PLC standard, known as PLC- 195 IOT, is suitable for 6lo applications thus mentioned in this 196 document. Details on this standard is to be determined. 198 3.1. Protocol Stack 200 The protocol stack for IPv6 over PLC is illustrated in Figure 1 that 201 contains the following elements from bottom to top: PLC PHY Layer, 202 PLC MAC Layer, Adaptation layer for IPv6 over PLC, IPv6 Layer, 203 TCP/UDP Layer and Application Layer. The PLC MAC/PHY layer 204 corresponds to a certain PLC standard such as IEEE 1901.2 or ITU-T 205 G.9903. For the Broadband PLC cases, the adaptation layer for IPv6 206 over PLC MAY not be used unless in some certain specifications. The 207 deployment of the 6lo adaptation layer are specified in section 4 208 according to different standards. Routing protocol like RPL on 209 Network layer is optional according to the specified PLC standard, 210 for example IEEE 1901.2 MAY use RPL protocol while ITU-T G.9903 MUST 211 NOT. 213 +----------------------------------------+ 214 | Application Layer | 215 +----------------------------------------+ 216 | TCP/UDP | 217 +----------------------------------------+ 218 | | 219 | IPv6 | 220 | | 221 |----------------------------------------| 222 | Adaptation layer for IPv6 over PLC | 223 +----------------------------------------+ 224 | PLC MAC Layer | 225 | (IEEE 1901.2 MAC/ITU-T G.9903 MAC) | 226 +----------------------------------------+ 227 | PLC PHY Layer | 228 | (IEEE 1901.2 PHY/ITU-T G.9903 PHY) | 229 +----------------------------------------+ 231 Figure 1: PLC Protocol Stack 233 3.2. Addressing Modes 235 Two addressing modes are enabled in PLC including the IEEE 64-bit 236 extended address and the 16-bit short address which is unique within 237 the PAN [IEEE 1901.2, ITU-T G.9903]. Physical addressing uses a 238 globally unique 64-bit address to represent each node on the 239 powerline. This is useful when initializing a system because the 240 nodes do not have unique logical addresses on power up. Logical 241 addressing uses 16-bit short address to represent each node on the 242 powerline with a much lower latency and higher throughput. Note that 243 in ITU-T G.9930, though two addressing modes are enabled, only 16-bit 244 addressing is supported in mesh routing. 246 3.3. Maximum Transmission Unit 248 Maximum Transmission Unit (MTU) of MAC layer is an important 249 parameter that determines the applicability of fragmentation and 250 reassembly at the adaptation layer of IPv6 over PLC. IPv6 requires 251 that every link in the Internet have an MTU of 1280 octets or 252 greater, thus for a MAC layer with MTU lower than this limit, 253 fragmentation and reassembly at the adaptation layer are required. 255 As a wired communication technology, the MTU of PLC MAC layer is 256 normally higher than wireless technology based on IEEE 802.15.4. The 257 IEEE 1901.2 MAC layer supports the MTU of 1576 octets (the original 258 value 1280 byte was updated in 2015 [IEEE 1901.2a]). The MTU for 259 ITU-T G.9903 is 400 octets, insufficient for supporting complete IPv6 260 packets. For this concern, fragmentation/reassembly in [RFC 4944] 261 MUST be enabled for the G.9903-based scenarios (details can be found 262 in section 4.2.5). 264 4. Specification of IPv6 over Narrowband PLC 266 Due to the narrow bandwidth and low data rate in NBPLC, a 6lo 267 adaptation layer is needed to support the transmission of IPv6 268 packets. 6LoWPAN standards [RFC 4944], [RFC 6775], and [RFC 6282] 269 provides useful functionality including link-local IPv6 addresses, 270 stateless address auto-configuration, neighbor discovery and header 271 compression. These standards are referred in the specifications of 272 the 6lo adaptation layer which is illustrated in the following 273 subsections. 275 4.1. IEEE 1901.2 277 4.1.1. Stateless Address Autoconfiguration 279 An IEEE 1901.2 device performs stateless address autoconfiguration 280 according to [RFC 4944] so as to obtain an IPv6 Interface Identifier 281 (IID). In the 16-bit short addressing mode, the 64-bit IID SHALL be 282 derived by insert 16-bit "FFEE" into a "pseudo 48-bit address" which 283 is formed by the 16-bit PAN ID, 16-bit zero and the 16-bit short 284 address as follows: 286 16_bit_PAN:00FF:FE00:16_bit_short_address 288 Considering that this derived IID is not globally unique, the 289 "Universal/Local" (U/L) bit (7th bit) SHALL be set to zero. 291 For the EUI-64 addressing mode, as per [RFC 2464], the Interface 292 Identifier is then formed from by complementing the U/L bit, 293 generally setting to 1, since an interface's built-in address is 294 expected to be globally unique. 296 4.1.2. IPv6 Link Local Address 298 The IPv6 link-local address [RFC4291] for an IEEE 1901.2 interface is 299 formed by appending the Interface Identifier, as defined above, to 300 the prefix FE80::/64 (see Figure 2). 302 10 bits 54 bits 64 bits 303 +----------+-----------------------+----------------------------+ 304 |1111111010| (zeros) | Interface Identifier | 305 +----------+-----------------------+----------------------------+ 307 Figure 2: IPv6 Link Local Address in IEEE 1901.2 309 4.1.3. Unicast and Multicast Address Mapping 311 The address resolution procedure for mapping IPv6 unicast addresses 312 into IEEE 1901.2 link-layer addresses follows the general description 313 in section 7.2 of [RFC4861], unless otherwise specified. 315 The Source/Target Link-layer Address option has the following forms 316 when the link layer is IEEE 1901.2 and the addresses are EUI-64 or 317 16-bit short addresses, respectively. 319 0 1 0 1 320 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 321 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 322 | Type | Length=2 | | Type | Length=1 | 323 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 324 | | | 16-bit short Address | 325 +- IEEE 1901.2 -+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 326 | EUI-64 | | Padding | 327 +- -+ +- -+ 328 | | | (all zeros) | 329 +- Address -+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 330 | | 331 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 332 | | 333 +- Padding -+ 334 | | 335 +- (all zeros) -+ 336 | | 337 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 339 Figure 3: Unicast Address Mapping in IEEE 1901.2 341 Option fields: 343 Type: 1 for Source Link-layer address and 2 for Target Link-layer 344 address. 346 Length: This is the length of this option (including the type and 347 length fields) in units of 8 octets. The value of this field is 2 if 348 using EUI-64 addresses, or 1 if using 16-bit short addresses. 350 IEEE 1901.2 Address: The 64-bit IEEE 1901.2 address, or the 16-bit 351 short address. This is the address the interface currently responds 352 to. This address may be different from the built-in address used to 353 derive the Interface Identifier, because of privacy or security 354 (e.g., of neighbor discovery) considerations. 356 Multicast address mapping is not supported in IEEE 1901.2. A link- 357 local multicast only reaches neighbors within direct physical 358 connectivity. IEEE 1901.2 excludes the functionality of multicast 359 either in [RFC 4944] or in coexistence modes with G3-PLC and PRIME. 360 However, IEEE 1901.2 supports the required MTU by IPv6, eliminating 361 the need of fragmentation and reassembly at the 6lo adaptation layer, 362 so the multicast functionality in this case is applicable and is 363 RECOMMENDED in this document. 365 4.1.4. Header Compression 366 The IEEE 1901.2 PHY layer supports a maximum PSDU (PHY Service Data 367 Unit) of 512 octets while the allowed PHY payload is smaller and can 368 change dynamically based on channel conditions. Due to the limited 369 PHY payload, header compression at 6lo adaptation layer is of great 370 importance and MUST be applied. The compression of IPv6 datagrams 371 within IEEE 1901.2 frames refers to [RFC 6282], which updates [RFC 372 4944]. Header compression as defined in RFC6282 which specifies the 373 fragmentation methods for IPv6 datagrams on top of IEEE 802.15.4, is 374 REQUIRED in this document as the basis for IPv6 header compression in 375 IEEE 1901.2. All headers MUST be compressed according to RFC6282 376 encoding formats. 378 4.1.5. Fragmentation and Reassembly 380 To cope with the mismatch between the size of the PHY frame payload 381 and the size of the MAC Service Data Unit (MSDU), IEEE 1901.2 MAC 382 layer provides the functionality of segmentation and reassembly. A 383 Segment Control Field is defined in the MAC frame header regardless 384 of whether segmentation is required. This process segments a MAC 385 layer datagram into multiple fragments and provides a reliable one- 386 hop transfer of the resulting fragments. However, for the 6lo 387 adaptation layer, since IEEE 1901.2 naturally supports a MAC payload 388 of 1280 octets, the minimum MTU of IPv6, there is no need for 389 fragmentation and reassembly for the IPv6 packet transmission. This 390 document specifies that, in the IPv6 packet transmission over IEEE 391 1901.2, fragmentation and reassembly in [RFC 4944] MUST NOT be used. 393 4.2. ITU-T G.9903 395 4.2.1. Stateless Address Autoconfiguration 397 The stateless address auto-configuration in ITU-T G.9903 also refers 398 to [RFC 4944] with the following selections: The 64-bit interface 399 identifier shall be derived from a "pseudo 48-bit address" formed 400 with the PAN identifier and the short address as follows: 401 0xYYYY:00FF:FE00:XXXX where 0xYYYY is the PAN identifier and XXXX is 402 the short address. Additional care shall be taken when choosing a 403 PAN identifier so as not to interfere with I/G and U/L bits of the 404 interface identifier. If the PAN identifiers are chosen randomly, 405 then the U/L and I/G bits (7th and 8th bits) shall be set to zero 406 [ITU-T G.9903]. 408 4.2.2. IPv6 Link Local Address 410 In ITU-T G.9903, the formation of IPv6 link-local address follows the 411 same process as IEEE 1901.2 (see section 4.1.2) by appending the 412 Interface Identifier (IID) to the prefix FE80::/64. 414 4.2.3. Unicast and Multicast Address Mapping 416 The address resolution procedure for mapping IPv6 unicast addresses 417 into ITU-T G.9903 link-layer addresses follows the general 418 description in section 7.2 of [RFC4861], unless otherwise specified. 419 Source/Target link-layer address option field SHOULD contain the EUI- 420 64 address or the combined address with PAN ID and 16-bit short 421 address of the source or target device as below. Note that the 422 format of the Target Link-layer address in ITU-T G.9903 (see Figure 423 4) is specified according to the Annex E of [ITU-T G.9903]. 425 0 1 0 1 426 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 427 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 428 | Type | Length=2 | | Type | Length=1 | 429 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 430 | | | PAN ID | 431 +- ITU-T G.9903 -+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 432 | EUI-64 | | 16-bit short Address | 433 +- -+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 434 | Address | | (all zeros) | 435 +- -+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 436 | | 437 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 438 | | 439 +- Padding -+ 440 | | 441 +- (all zeros) -+ 442 | | 443 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 445 Figure 4: Unicast Address Mapping in ITU-T G.9903 447 Option fields: 449 Type: 1 for Source Link-layer address and 2 for Target Link-layer 450 address. 452 Length: This is the length of this option (including the type and 453 length fields) in units of 8 octets. The value of this field is 2 if 454 using EUI-64 addresses, or 1 if using 16-bit short addresses. 456 ITU-T G.9903 Address: The 64-bit IEEE 1901.2 address, or the 16-bit 457 short address. This is the address the interface currently responds 458 to. This address may be different from the built-in address used to 459 derive the Interface Identifier, because of privacy or security 460 (e.g., of neighbor discovery) considerations. 462 The address resolution procedure for mapping IPv6 multicast addresses 463 into ITU-T G.9903 link-layer addresses follows the general 464 description in [RFC 4944] and MUST only be used in a mesh-enabled 465 network. An IPv6 packet with a multicast destination address (DST), 466 consisting of the sixteen octets DST[1] through DST[16], is 467 transmitted to the following 802.15.4 16-bit multicast address (see 468 Figure 5): 470 0 1 471 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 472 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 473 |1 0 0|DST[15]* | DST[16] | 474 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 476 Figure 5: Multicast Address Mapping 478 Here, DST[15]* refers to the last 5 bits in octet DST[15], that is, 479 bits 3-7 within DST[15]. The initial 3-bit pattern of "100" follows 480 the 16-bit address format for multicast addresses (see Section 12 of 481 [RFC 4944]). 483 4.2.4. Header Compression 485 Header compression as defined in [RFC6282], which specifies the 486 compression format for IPv6 datagrams on top of IEEE 802.15.4, is 487 REQUIRED in this document as the basis for IPv6 header compression in 488 ITU-T G.9903. All headers MUST be compressed according to [RFC6282] 489 encoding formats. 491 4.2.5. Fragmentation and Reassembly 493 Similar to IEEE 1901.2, Segment Control Field is also defined in the 494 ITU-T G.9903 MAC frame header, and the functionality of fragmentation 495 and reassembly is also enabled at the G.9903 MAC layer. However, the 496 maximum MAC payload size is fixed to 400 octets at the present ITU-T 497 G.9903 recommendation, thus to cope with the required MTU of 1280 498 octets by IPv6, fragmentation and reassembly at 6lo adaptation layer 499 MUST be provided referring to [RFC 4944]. 501 To avoid the duplicate fragmentation at both 6lo adaptation layer and 502 ITU-T G.9903 MAC layer, an optional way is to limit the MAC payload 503 size so that the MSDU can fit the PHY payload without MAC layer 504 fragmentation. However, the number of data bytes of the PHY payload 505 can change dynamically based on channel conditions (see section 9.3 506 in [ITU-T G.9903]), so the best solution is incrementing the allowed 507 MAC payload size above 1280 octets so as to avoid the use of 508 fragmentation and reassembly at 6lo adaptation layer. 510 4.2.6. Extension at 6lo Adaptation Layer 512 Apart from the 6Lo headers specified in [RFC 4944], an additional 513 command frame header is defined for the mesh routing procedure which 514 appears in the following order: Mesh addressing header, Broadcast 515 header, Fragmentation header, Command frame header [ITU-T G.9903]. 517 Figure 6 shows an example of the command frame: The ESC header type 518 (01000000b) indicates an additional dispatch byte follows (see [RFC 519 4944] and [RFC 6282]). Then this 1-octet dispatch field is used as 520 the Command frame header and filled with the Command ID. This header 521 shall be in the last position if more than one header is present in 522 the frame. The Command ID can be classified into 4 types: 524 - LOADng message (0x01) 526 - LoWPAN bootstrapping protocol message (0x02) 528 - Reserved by ITU-T (0x03-0x0F) 530 - CMSR protocol messages (0X10-0X1F) 532 0 1 2 533 Bits 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 534 +---------------+---------------+----------------- 535 |ESC header type| | 536 | | Command ID | Command Payload 537 | 01 000000b | | 538 +---------------+---------------+----------------- 540 Figure 6: Command Frame Header Format of ITU-T G.9903 542 For the Mesh addressing type and header, it is worthy to note that 543 the value of the HopsLeft field SHALL not exceed adpMaxHops. When 544 the originator and final destination devices are neighbors (i.e., the 545 next hop address equals the final destination address and the next 546 hop address is present in the originator's neighbor table), the mesh 547 header shall be omitted in the frame. 549 5. Internet Connectivity Scenarios and Topologies 551 The network model can be simplified to two kinds of network devices: 552 Border Router (BR) and Node. BR is the coordinator of the PLC subnet 553 and can be seen as a master node while Nodes are typically PLC meters 554 and sensors. The IPv6 over PLC networks SHOULD be built as tree, 555 mesh or star according to the specified using scenarios. Every 556 network requires at least one BR to communicate with each nodes. 558 One common topology in the current PLC scenarios is star. In this 559 case, the communication at the link layer only takes place between a 560 node and a BR. The BR collects data (e.g. smart meter reading) from 561 different nodes, and then concentrates and uploads the data through 562 Ethernet or LPWAN (see Figure 7). The collected data is transmitted 563 by the smart meters through PLC, aggregated by a concentrator, sent 564 to the utility and then to a Meter Data Management System for data 565 storage, analysis and billing. 567 Node Node 568 \ / +--------- 569 \ / / 570 \ / + 571 \ / | 572 Node ------ BR =========== | Internet 573 / \ | 574 / \ + 575 / \ \ 576 / \ +--------- 577 Node Node 579 <----------------------> 580 PLC subnet 582 Figure 7: PLC Star Network connected to the Internet 584 Tree topology is used when the distance between a node A and BR is 585 beyond the PLC allowed limit while there is another node B in between 586 able to communicate with both sides. Node B in this case acts both 587 as a 6lo Node and a Proxy Coordinator (PCO). For this scenario, the 588 link layer communications take place between node A and node B, and 589 between node B and BR. An example of PLC tree network is depicted in 590 Figure 8. This topology can be applied in the smart street lighting, 591 where the lights adjust the brightness to reduce energy consumption 592 while sensors are deployed on the street lights to give information 593 such as wind speed, temperature, humidity. Data transmission 594 distance in the street lighting scenario is normally above several 595 kilometers thus the PLC tree network is required. A more 596 sophisticated AMI network may also be constructed into the tree 597 topology which as depicted in [RFC 8036]. 599 Node 600 \ +--------- 601 Node \ / 602 \ \ + 603 \ \ | 604 Node --- Node ----- BR ========== | Internet 605 / / | 606 / / + 607 Node --- Node / \ 608 / +--------- 609 Node --- Node 611 <-------------------------> 612 PLC subnet 614 Figure 8: PLC Tree Network connected to the Internet 616 Mesh networking in PLC is still under development but of great 617 potential applications. By connecting all nodes with their neighbors 618 in communication range (see Figure 9), mesh topology dramatically 619 enhances the communication efficiency and thus expands the size of a 620 PLC network. A simple use case is the smart home scenario where the 621 ON/OFF state of air conditioning is controlled by the state of home 622 lights (ON/OFF) and doors (OPEN/CLOSE). 624 Node ----- Node 625 / \ / \ +--------- 626 / \ / \ / 627 / \ / \ + 628 / \ / \ | 629 Node --- Node ---- Node ----- BR =========== | Internet 630 \ / \ / | 631 \ / \ / + 632 \ / \ / \ 633 \ / \ / +--------- 634 Node ----- Node 636 <---------------------------------> 637 PLC subnet 639 Figure 9: PLC Mesh Network connected to the Internet 641 6. IANA Considerations 643 There are no IANA considerations related to this document. 645 7. Security Consideration 646 This document has no security consideration beyond those in [RFC 647 4944] and [RFC 6282]. 649 8. References 651 8.1. Normative References 653 [IEEE 1901.2] IEEE-SA Standards Board, "IEEE Standard for Low- 654 Frequency (less than 500 kHz) Narrowband Power Line 655 Communications for Smart Grid Applications", IEEE 1901.2, 656 October 2013, 657 . 660 [ITU-T G.9903] International Telecommunication Union, "Narrowband 661 orthogonal frequency division multiplexing power line 662 communication transceivers for G3-PLC networks", ITU-T 663 G.9903, February 2014, . 666 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 667 Requirement Levels", BCP 14, RFC 2119, DOI 668 10.17487/RFC2119, March 1997, . 671 [RFC2464] Crawford, M., "Transmission of IPv6 Packets over Ethernet 672 Networks", RFC 2464, December 1998, . 675 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 676 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, DOI 677 10.17487/RFC4861, September 2007, . 680 [RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler, 681 "Transmission of IPv6 Packets over IEEE 802.15.4 Networks", 682 RFC 4944, September 2007, . 685 [RFC6282] Hui, J. and P. Thubert, "Compression Format for IPv6 686 Datagrams over IEEE 802.15.4-Based Networks", RFC 6282, 687 September 2011, . 689 8.2. Informative References 691 [draft-popa-6lo-6loplc] Popa, D. and J.H. Hui, "6LoPLC: Transmission 692 of IPv6 Packets over IEEE 1901.2 Narrowband Powerline 693 Communication Networks", draft-popa-6lo-6loplc-ipv6-over- 694 ieee19012-networks-00, March 2014, 695 . 698 [IEEE 1901.1] IEEE-SA Standards Board, "Standard for Medium Frequency 699 (less than 15 MHz) Power Line Communications for Smart Grid 700 Applications", IEEE 1901.1, work in progress, 701 . 703 [IEEE 1901.2a] IEEE-SA Standards Board, "IEEE Standard for Low- 704 Frequency (less than 500 kHz) Narrowband Power Line 705 Communications for Smart Grid Applications - Amendment 1", 706 IEEE 1901.2a, September 2015, 707 . 710 [ITU-T G.9960] International Telecommunication Union, "Unified high- 711 speed wireline-based home networking transceivers - System 712 architecture and physical layer specification", ITU-T 713 G.9960, December 2011, . 716 [ITU-T G.9961] International Telecommunication Union, "Unified high- 717 speed wireline-based home networking transceivers - Data 718 link layer specification", ITU-T G.9961, June 2010, 719 . 721 [RFC 8036] Cam-Winget, N., Hui, J. and D. Popa, "Applicability 722 Statement for the Routing Protocol for Low-Power and Lossy 723 Networks (RPL) in Advanced Metering Infrastructure (AMI) 724 Networks", RFC 8036, January 2017, . 727 9. Acknowledgments 729 Authors wish to thank Yizhou Li and Yuefeng Wu for their valuable 730 comments and contributions. 732 Authors' Addresses 734 Jianqiang Hou 735 Huawei Technologies 736 101 Software Avenue, 737 Nanjing 210012 738 China 740 Phone: +86 15852944235 741 Email: houjianqiang@huawei.com 742 Yong-Geun Hong 743 Electronics and Telecommunications Research Institute 744 161 Gajeong-Dong Yuseung-Gu 745 Daejeon 305-700 746 Korea 748 Phone: +82 42 860 6557 749 Email: yghong@etri.re.kr 751 Xiaojun Tang 752 State Grid Electric Power Research Institute 753 19 Chengxin Avenue 754 Nanjing 211106 755 China 757 Phone: +86-25-81098508 758 Email: itc@sgepri.sgcc.com.cn