[Docs] [txt|pdf] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03 04

6Lo Working Group                                                 J. Hou
Internet-Draft                                                    B. Liu
Intended status: Standards Track                     Huawei Technologies
Expires: January 2, 2019                                       Y-G. Hong
                                                                    ETRI
                                                                 X. Tang
                                                                  SGEPRI
                                                              C. Perkins
                                                               Futurewei
                                                            July 1, 2018


             Transmission of IPv6 Packets over PLC Networks
                          draft-hou-6lo-plc-04

Abstract

   Power Line Communication (PLC), namely using the electric-power lines
   for indoor and outdoor communications, has been widely applied to
   support Advanced Metering Infrastructure (AMI), especially smart
   meters for electricity.  The inherent advantage of existing
   electricity infrastructure facilitates the expansion of PLC
   deployments, and moreover, a wide variety of accessible devices
   raises the potential demand of IPv6 for future applications.  This
   document describes how IPv6 packets are transported over constrained
   PLC networks, such as ITU-T G.9903, IEEE 1901.1, IEEE 1901.2 and IEEE
   1901.2a.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at https://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on January 2, 2019.







Hou, et al.              Expires January 2, 2019                [Page 1]


Internet-Draft                IPv6 over PLC                    July 2018


Copyright Notice

   Copyright (c) 2018 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (https://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
   2.  Requirements Notation and Terminology . . . . . . . . . . . .   3
   3.  Overview of PLC . . . . . . . . . . . . . . . . . . . . . . .   4
     3.1.  Protocol Stack  . . . . . . . . . . . . . . . . . . . . .   5
     3.2.  Addressing Modes  . . . . . . . . . . . . . . . . . . . .   5
     3.3.  Maximum Transmission Unit . . . . . . . . . . . . . . . .   6
     3.4.  Routing Protocol  . . . . . . . . . . . . . . . . . . . .   6
   4.  IPv6 over PLC . . . . . . . . . . . . . . . . . . . . . . . .   7
     4.1.  Stateless Address Autoconfiguration . . . . . . . . . . .   7
     4.2.  IPv6 Link Local Address . . . . . . . . . . . . . . . . .   8
     4.3.  Unicast Address Mapping . . . . . . . . . . . . . . . . .   8
       4.3.1.  Unicast Address Mapping for IEEE 1901.1 . . . . . . .   8
       4.3.2.  Unicast Address Mapping for IEEE 1901.2 and ITU-T
               G.9903  . . . . . . . . . . . . . . . . . . . . . . .   9
     4.4.  Neighbor Discovery  . . . . . . . . . . . . . . . . . . .  10
     4.5.  Header Compression  . . . . . . . . . . . . . . . . . . .  10
     4.6.  Fragmentation and Reassembly  . . . . . . . . . . . . . .  11
     4.7.  Extension at 6lo Adaptation Layer . . . . . . . . . . . .  11
   5.  Internet Connectivity Scenarios and Topologies  . . . . . . .  12
   6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  15
   7.  Security Consideration  . . . . . . . . . . . . . . . . . . .  15
   8.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .  15
   9.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  15
     9.1.  Normative References  . . . . . . . . . . . . . . . . . .  15
     9.2.  Informative References  . . . . . . . . . . . . . . . . .  17
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  18








Hou, et al.              Expires January 2, 2019                [Page 2]


Internet-Draft                IPv6 over PLC                    July 2018


1.  Introduction

   The idea of using power lines for both electricity supply and
   communication can be traced back to the beginning of the last
   century.  With the advantage of existing power grid, Power Line
   Communication (PLC) is a good candidate for supporting various
   service scenarios such as in houses and offices, in trains and
   vehicles, in smart grid and advanced metering infrastructure (AMI).
   Such applications cover the smart meters for electricity, gas and
   water that share common features such as fixed position, large
   quantity, low data rate, and long life time.

   Although PLC technology has evolved over several decades, it has not
   been fully adapted for IPv6 based constrained networks.  The 6lo
   related scenarios lie in the low voltage PLC networks with most
   applications in the area of Advanced Metering Infrastructure (AMI),
   Vehicle-to-Grid communications, in-home energy management and smart
   street lighting.  IPv6 is important for PLC networks, due to its
   large address space and efficent address auto-configuration.  A
   comparison among various existing PLC standards is provided to
   facilitate the selection of the most applicable standard in
   particular scenarios.

   The following sections provide a brief overview of PLC, then describe
   transmission of IPv6 packets over PLC networks.  The general approach
   is to adapt elements of the 6LoWPAN specifications [RFC4944],
   [RFC6282], and [RFC6775] to constrained PLC networks.  Compared to
   [I-D.popa-6lo-6loplc-ipv6-over-ieee19012-networks], this document
   provides a structured and greatly expanded specification of an
   adaptation layer for IPv6 over PLC (6LoPLC) networks.

2.  Requirements Notation and Terminology

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
   "OPTIONAL" in this document are to be interpreted as described in
   [RFC2119].

   This document often uses the following acronyms:

   6LoWPAN:  IPv6 over Low-Power Wireless Personal Area Network

   AMI:  Advanced Metering Infrastructure

   BBPLC:  Broadband Power Line Communication

   CID:  Context ID




Hou, et al.              Expires January 2, 2019                [Page 3]


Internet-Draft                IPv6 over PLC                    July 2018


   DAD:  Duplicate Address Detection

   EV:   Electric Vehicle

   HDPLC:  High Definition Power Line Communication

   IID:  IPv6 Interface Identifier

   IPHC: IP Header Compression

   LAN:  Local Area Network

   LOADng:  Lightweight On-demand Ad-hoc Distance-vector Routing
         Protocol Next Generation

   MSDU: MAC Service Data Unit

   MTU:  Maximum Transmission Unit

   NBPLC:  Narrowband Power Line Communication

   OFDM: Orthogonal Frequency Division Multiplexing

   PCO:  PAN Coordinator

   PLC:  Power Line Communication

   PSDU: PHY Service Data Unit

   RPL:  IPv6 Routing Protocol for Low-Power and Lossy Networks

   RA:   Router Advertisement

   WAN:  Wide Area Network

3.  Overview of PLC

   PLC technology enables convenient two-way communications for home
   users and utility companies to monitor and control electric plugged
   devices such as electricity meters and street lights.  Due to the
   large range of communication frequencies, PLC is generally classified
   into two categories: Narrowband PLC (NBPLC) for automation of
   sensors, and Broadband PLC (BBPLC) for home and industry networking
   applications.  Various standards have been addressed on the MAC and
   PHY layers for this communication technology, e.g.  BBPLC (1.8-250
   MHz) including IEEE 1901 and ITU-T G.hn, and NBPLC (3-500 kHz)
   including IEEE 1901.2 [IEEE_1901.2], ITU-T G.9902 (G.hnem), ITU-T
   G.9903 (G3-PLC) [ITU-T_G.9903] and ITU-T G.9904 (PRIME).  And



Hou, et al.              Expires January 2, 2019                [Page 4]


Internet-Draft                IPv6 over PLC                    July 2018


   moreover, recently a new PLC standard IEEE 1901.1 [IEEE_1901.1],
   which aims at the medium frequency band less than 12 MHz, has been
   published by the IEEE standard for Smart Grid Powerline Communication
   Working Group (SGPLC WG).

   Narrowband PLC is an important branch of PLC technology due to its
   low frequency band and low power cost.  So far the recent PLC
   standards, ITU-T G.9903 (G3-PLC) and IEEE 1901.2, are dominating as
   two of the most robust schemes available.  IEEE 1901.2 is a
   combination of G3-PLC and PRIME while IEEE 1901.2a [IEEE_1901.2a] is
   an amendment to IEEE 1901.2.  IEEE 1901.1 balances the needs for
   bandwidth versus communication range, and is thus a promising option
   for the 6lo applications mentioned above.

3.1.  Protocol Stack

   The protocol stack for IPv6 over PLC is illustrated in Figure 1.  The
   PLC MAC/PHY layer corresponds to IEEE 1901.1, IEEE 1901.2 or ITU-T
   G.9903.  The 6lo adaptation layer for PLC is illustrated in
   Section 4.  A routing protocol (e.g., RPL [RFC6550] or AODV-RPL
   [I-D.ietf-roll-aodv-rpl]) at the Network layer is optional according
   to the IEEE 1901.1 and IEEE 1901.2 PLC standards mentioned in this
   document.

                    +----------------------------------------+
                    |           Application Layer            |
                    +----------------------------------------+
                    |                TCP/UDP                 |
                    +----------------------------------------+
                    |                                        |
                    |                  IPv6                  |
                    |                                        |
                    +----------------------------------------+
                    |   Adaptation layer for IPv6 over PLC   |
                    +----------------------------------------+
                    |             PLC MAC Layer              |
                    +----------------------------------------+
                    |             PLC PHY Layer              |
                    +----------------------------------------+

                       Figure 1: PLC Protocol Stack

3.2.  Addressing Modes

   Each PLC device has a globally unique long address of 48-bit
   ([IEEE_1901.1]) or 64-bit ([IEEE_1901.2], [ITU-T_G.9903]) and a short
   address of 12-bit ([IEEE_1901.1]) or 16-bit ([IEEE_1901.2],
   [ITU-T_G.9903]).  The long address is set by the manufacturer



Hou, et al.              Expires January 2, 2019                [Page 5]


Internet-Draft                IPv6 over PLC                    July 2018


   according to the IEEE EUI-48 MAC address or the IEEE EUI-64 address.
   Each PLC device joins the network by using the long address and
   communicates with other devices by using the short address after
   joining the network.

3.3.  Maximum Transmission Unit

   The Maximum Transmission Unit (MTU) of the MAC layer determines
   whether fragmentation and reassembly are needed at the adaptation
   layer of IPv6 over PLC.  IPv6 requires an MTU of 1280 octets or
   greater; thus for a MAC layer with MTU lower than this limit,
   fragmentation and reassembly at the adaptation layer are required.

   The IEEE 1901.1 MAC supports upper layer packets up to 2031 octets.
   The IEEE 1901.2 MAC layer supports the MTU of 1576 octets (the
   original value of 1280 bytes was updated in 2015 [IEEE_1901.2a]).
   Though fragmentation and reassembly are not needed in these two
   technologies, other 6lo functions like header compression are still
   applicable and useful, particularly in high-noise communication
   environments.

   The MTU for ITU-T G.9903 is 400 octets, insufficient for supporting
   IPv6's MTU.  For this reason, fragmentation and reassembly as per
   [RFC4944] MUST be enabled for G.9903-based networks.

3.4.  Routing Protocol

   Routing algorithms suitable for use in PLC networks for AMI
   applications include:

   o  RPL (Routing Protocol for Low-Power and Lossy Networks) [RFC6550]
      is a routing protocol (operating at layer 3).  AODV-RPL augments
      RPL to include reactive, point-to-point, and asymmetric routing.

   o  ITU-T G.9903 [ITU-T_G.9903] uses LOADng which is a reactive
      protocol, operating in layer 2 or layer 3.

   o  IEEE 1901.1 supports L2 routing, in which the routing entries are
      built using short addresses.

   IEEE 1901.2 specifies additional Information Elements (IEs), with
   user-defined content, to supply PHY layer metrics for the IP layer.
   These IEs enable routing protocols to be used in 1901.2 networks.
   For IPv6-addressable PLC networks, a layer-3 routing protocol such as
   RPL and/or AODV-RPL SHOULD be supported in the standard.  Currently,
   LOADng is supported in ITU-T G.9903, and the IEEE 1901.2 standard
   refers to ITU-T G.9903 for LOAD-based networks.




Hou, et al.              Expires January 2, 2019                [Page 6]


Internet-Draft                IPv6 over PLC                    July 2018


4.  IPv6 over PLC

   6LoWPAN standards [RFC4944], [RFC6775], and [RFC6282] provides useful
   functionality including link-local IPv6 addresses, stateless address
   auto-configuration, neighbor discovery and header compression.
   However, due to the different characteristics of the PLC media, the
   6LoWPAN adaptation layer cannot perfectly fulfill the requirements.
   Besides, some of the features like fragmentation and reassembly are
   redudant to some PLC technologies.  Therefore, it is necessary to
   have a dedicated adaptation layer for PLC, which is detailed in the
   following subsections.

4.1.  Stateless Address Autoconfiguration

   To obtain an IPv6 Interface Identifier (IID), a PLC device performs
   stateless address autoconfiguration [RFC4944].  The autoconfiguration
   can be based on either a long or short link-layer address.

   The IID can be based on the device's 48-bit MAC address or its EUI-64
   identifier [EUI-64].  A 48-bit MAC address MUST first be extended to
   a 64-bit Interface ID by inserting 0xFFFE at the fourth and fifth
   octets as specified in [RFC2464].  The IPv6 IID is derived from the
   64-bit Interface ID by inverting the U/L bit [RFC4291].

   For IEEE 1901.2 and ITU-T G.9903, a 48-bit "pseudo-address" is formed
   by the 16-bit PAN ID, 16 zero bits and the 16-bit short address.
   Then, the 64-bit Interface ID MUST be derived by inserting 16-bit
   0xFFFE into as follows:

       16_bit_PAN:00FF:FE00:16_bit_short_address

   For the 12-bit short addresses used by IEEE 1901.1, the 48-bit
   pseudo-address is formed by 24-bit NID (Network IDentifier, YYYYYY),
   12 zero bits and a 12-bit TEI (Terminal Equipment Identifier, XXX).
   The 64-bit Interface ID MUST be derived by inserting 16-bit 0xFFFE
   into this 48-bit pseudo-address as follows:

       YYYY:YYFF:FE00:0XXX

   Since the derived Interface ID is not global, the "Universal/Local"
   (U/L) bit (7th bit) and the Individual/Group bit (8th bit) MUST both
   be set to zero.  In order to avoid any ambiguity in the derived
   Interface ID, these two bits MUST NOT be used to generate the PANID
   (for IEEE 1901.2 and ITU-T G.9903) or NID (for IEEE 1901.1).  In
   other words, the PANID or NID MUST always be chosen so that these
   bits are zeros.





Hou, et al.              Expires January 2, 2019                [Page 7]


Internet-Draft                IPv6 over PLC                    July 2018


4.2.  IPv6 Link Local Address

   The IPv6 link-local address [RFC4291] for a PLC interface is formed
   by appending the IID, as defined above, to the prefix FE80::/64 (see
   Figure 2).

       10 bits           54 bits                   64 bits
     +----------+-----------------------+----------------------------+
     |1111111010|        (zeros)        |    Interface Identifier    |
     +----------+-----------------------+----------------------------+

           Figure 2: IPv6 Link Local Address for a PLC interface

4.3.  Unicast Address Mapping

   The address resolution procedure for mapping IPv6 unicast addresses
   into PLC link-layer addresses follows the general description in
   section 7.2 of [RFC4861].  [RFC6775] improves this procedure by
   eliminating usage of multicast NS.  The resolution is realized by the
   NCEs (neighbor cache entry) created during the address registration
   at the routers.  6775-update further improves the registration
   procedure by enabling multiple LLNs to form an IPv6 subnet, and by
   inserting a link-local address registration to better serve proxy
   registration of new devices.

4.3.1.  Unicast Address Mapping for IEEE 1901.1

   The Source/Target Link-layer Address options for IEEE_1901.1 used in
   the Neighbor Solicitation and Neighbor Advertisement have the
   following form.

     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
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |     Type      |    Length=1   |              NID              :
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    :NID (continued)|  Padding (all zeros)  |          TEI          |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

             Figure 3: Unicast Address Mapping for IEEE 1901.1

   Option fields:

   Type: 1 for Source Link-layer Address and 2 for Target Link-layer
         Address.

   Length:  The length of this option (including type and length fields)
         in units of 8 octets.  The value of this field is 1 for the
         12-bit IEEE 1901.1 PLC short addresses.



Hou, et al.              Expires January 2, 2019                [Page 8]


Internet-Draft                IPv6 over PLC                    July 2018


   NID:  24-bit Network IDentifier

   Padding:  12 zero bits

   TEI:  12-bit Terminal Equipment Identifier

   In order to avoid the possibility of duplicated IPv6 addresses, the
   value of the NID MUST be chosen so that the 7th and 8th bits of the
   first byte of the NID are both zero.

4.3.2.  Unicast Address Mapping for IEEE 1901.2 and ITU-T G.9903

   The Source/Target Link-layer Address options for IEEE_1901.2 and
   ITU-T G.9903 used in the Neighbor Solicitation and Neighbor
   Advertisement have the following form.

      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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |     Type      |    Length=1   |             PAN ID            |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |       Padding (all zeros)     |         Short Address         |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

             Figure 4: Unicast Address Mapping for IEEE 1901.2

   Option fields:

   Type: 1 for Source Link-layer Address and 2 for Target Link-layer
         Address.

   Length:  The length of this option (including type and length fields)
         in units of 8 octets.  The value of this field is 1 for the
         16-bit IEEE 1901.2 PLC short addresses.

   PAN ID:  16-bit PAN IDentifier

   Padding:  16 zero bits

   Short Address:  16-bit short address

   In order to avoid the possibility of duplicated IPv6 addresses, the
   value of the PAN ID MUST be chosen so that the 7th and 8th bits of
   the first byte of the PAN ID are both zero.








Hou, et al.              Expires January 2, 2019                [Page 9]


Internet-Draft                IPv6 over PLC                    July 2018


4.4.  Neighbor Discovery

   Neighbor discovery procedures for 6LoWPAN networks are described in
   Neighbor Discovery Optimization for 6LoWPANs [RFC6775] and
   [I-D.ietf-6lo-rfc6775-update].  These optimizations support the
   registration of sleeping hosts.  Although PLC devices are
   electrically powered, sleeping mode SHOULD still be used for power
   saving.

   RFC6775-only [RFC6775] PLC devices follow Sections 5.3 and 5.4 of
   that specification for sending Router Solicitations and processing
   Router Advertisements to acquire the IPv6 prefix and context
   information.  Such a PLC host MUST register its address to the router
   using Neighbor Solicitation and Neighbor Advertisement messages.  In
   addition, if DHCPv6 is used to assign addresses, or the IPv6 address
   is derived by unique long or short link layer address, Duplicate
   Address Detection (DAD) MUST NOT be utilized.

   RFC6775-update [I-D.ietf-6lo-rfc6775-update] PLC devices include the
   EARO with the 'R' flag set when sending Router Solicitations, and
   process Router Advertisements that include EARO to extract status
   information.  Duplicate Address Detection is in this case proxied by
   a routing registrar, which MAY operate according to Optimistic DAD
   (ODAD) [RFC4429].  For networks with mixed RFC6775-only and
   RFC6775-update devices, the RFC6775-update PLC devices MUST use a
   64-bit ROVR.

   If the PLC network uses route-over mesh, the IPv6 prefix MAY be
   disseminated by the layer 3 routing protocol, such as RPL which
   includes the prefix in the DIO message.  The prefix information
   option (PIO) MUST NOT be included in the Router Advertisement.

   The mesh-under ITU-T G.9903 network SHOULD NOT utilize the address
   registration as described in [RFC6775].  ITU-T G.9903 PLC networks
   MUST use the 6LoWPAN Context Option (6CO) specified in [RFC6775] (see
   clause 9.4.1.1 in [ITU-T_G.9903]), which can be attached in Router
   Advertisements to disseminate Context IDs (CIDs) to use for
   compressing prefixes.  An implementation for mesh-under operation
   MUST use [RFC6775] mechanisms for managing IPv6 prefixes and
   corresponding header compression context information [RFC6282].

4.5.  Header Compression

   The compression of IPv6 datagrams within PLC MAC frames refers to
   [RFC6282], which updates [RFC4944].  Header compression as defined in
   [RFC6282] which specifies the compression format for IPv6 datagrams
   on top of IEEE 802.15.4, is included in this document as the basis
   for IPv6 header compression in PLC.  For situations when PLC MAC MTU



Hou, et al.              Expires January 2, 2019               [Page 10]


Internet-Draft                IPv6 over PLC                    July 2018


   cannot support the 1280-octet IPv6 packet, headers MUST be compressed
   according to [RFC6282] encoding formats.

4.6.  Fragmentation and Reassembly

   PLC differs from other wired technologies in that the communication
   medium is not shielded; thus, to successfully transmit data through
   power lines, PLC Data Link layer provides the function of
   segmentation and reassembly.  A Segment Control Field is defined in
   the MAC frame header regardless of whether segmentation is required.
   The number of data octets of the PHY payload can change dynamically
   based on channel conditions, thus the MAC payload segmentation in the
   MAC sublayer is enabled and guarantees a reliable one-hop data
   transmission.

   In IEEE 1901.1 and IEEE 1901.2, since the MAC layer supports a
   payload of respectively 2031 octets and 1576 octets, which is larger
   than the minimum MTU required by IPv6 packets, there is no need of
   fragmentation for the IPv6 packet transmission, thus the
   fragmentation and reassembly defined in [RFC4944] MUST NOT be used in
   the 6lo adaptation layer of IEEE 1901.2.

   In ITU-T G.9903, the maximum MAC payload size is fixed to 400 octets,
   so to cope with the required MTU of 1280 octets by IPv6,
   fragmentation and reassembly at 6lo adaptation layer MUST be provided
   referring to [RFC4944].

4.7.  Extension at 6lo Adaptation Layer

   Apart from the Dispatch and LOWPAN_IPHC headers specified in
   [RFC4944], an additional Command Frame Header is needed for the mesh
   routing procedure in LOADng protocol.  Figure 5 illustrates the
   format of the Command Frame Header [RFC8066].  The ESC dispatch type
   (01000000b) indicates an ESC extension type follows (see [RFC4944]
   and [RFC6282]).  Then this 1-octet dispatch field is used as the
   Command Frame Header and filled with the Command ID.  The Command ID
   can be classified into 4 types:

   o  LOADng message (0x01)

   o  LoWPAN bootstrapping protocol message (0x02)

   o  Reserved by ITU-T (0x03-0x0F)

   o  CMSR protocol messages (0X10-0X1F)

   The LOADng message is used to provide the default routing protocol
   LOADng while the LoWPAN bootstrapping protocol message is for the



Hou, et al.              Expires January 2, 2019               [Page 11]


Internet-Draft                IPv6 over PLC                    July 2018


   LoWPAN bootstrap procedure.  The CMSR protocol messages are specified
   for the Centralized metric-based source routing [ITU-T G.9905] which
   is out of the scope of this draft.

      0                   1                   2                   3
      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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |      ESC      |  Command ID   |     Command Payload
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

           Figure 5: Command Frame Header Format of ITU-T G.9903

   Command Frame Header appears in the last position if more than one
   header is present in the 6LoWPAN frame [ITU-T_G.9903].  On the other
   hand, this Command Frame Header MUST appear before the LoWPAN_IPHC
   dispatch type as per[RFC8066].

   o  Regarding the order of the command frame header, the inconsistency
      between G.9903 and RFC8066 still exists and is being solved in
      ITU-T SG15/Q15.

   Following these two requirements of header order mentioned above, an
   example of the header order is illustrated in Figure 6 including the
   Fragmentation type, Fragmentation header, ESC dispatch type, ESC
   Extension Type (Command ID), ESC Dispatch Payload (Command Payload),
   LOWPAN_IPHC Dispatch Type, LOWPAN_IPHC header, and Payload.

     +-----+-----+-----+-----+-----+--------+---------------+------+
     |F typ|F hdr| ESC | EET | EDP |Dispatch|LOWPAN_IPHC hdr| Payld|
     +-----+-----+-----+-----+-----+--------+---------------+------+

       Figure 6: A 6LoWPAN packet including the Command Frame Header

5.  Internet Connectivity Scenarios and Topologies

   The network model can be simplified to two kinds of network devices:
   PAN Coordinator (PCO) and PAN Device.  The PCO is the coordinator of
   the PLC subnet and can be seen as a master node; PAN Devices are
   typically PLC meters and sensors.  The PCO also serves as the Routing
   Registrar for proxy registration and DAD procedures, making use of
   the updated registration procedures in [I-D.ietf-6lo-rfc6775-update].
   IPv6 over PLC networks are built as tree, mesh or star according to
   the use cases.  Every network requires at least one PCO to
   communicate with each PAN Device.  Note that the PLC topologies in
   this section are based on logical connectivity, not physical links.

   The star topology is common in current PLC scenarios.  In star
   topologies, communication at the link layer only takes place between



Hou, et al.              Expires January 2, 2019               [Page 12]


Internet-Draft                IPv6 over PLC                    July 2018


   a PAN Device and a PCO.  The PCO typically collects data (e.g. smart
   meter reading) from the PAN devices, and then concentrates and
   uploads the data through Ethernet or LPWAN (see Figure 7).  The
   collected data is transmitted by the smart meters through PLC,
   aggregated by a concentrator, sent to the utility and then to a Meter
   Data Management System for data storage, analysis and billing.  This
   topology has been widely applied in the deployment of smart meters,
   especially in apartment buildings.

                   PAN Device   PAN Device
                         \        /           +---------
                          \      /           /
                           \    /           +
                            \  /            |
          PAN Device ------  PCO ===========+  Internet
                            /  \            |
                           /    \           +
                          /      \           \
                         /        \           +---------
                   PAN Device   PAN Device

                <---------------------->
               PLC subnet (IPv6 over PLC)

           Figure 7: PLC Star Network connected to the Internet

   A tree topology is useful when the distance between a device A and
   PCO is beyond the PLC allowed limit and there is another device B in
   between able to communicate with both sides.  Device B in this case
   acts both as a PAN Device and a Proxy Coordinator.  For this
   scenario, the link layer communications take place between device A
   and device B, and between device B and PCO.  An example of PLC tree
   network is depicted in Figure 8.  This topology can be applied in the
   smart street lighting, where the lights adjust the brightness to
   reduce energy consumption while sensors are deployed on the street
   lights to provide information such as light intensity, temperature,
   humidity.  Data transmission distance in the street lighting scenario
   is normally above several kilometers thus the PLC tree network is
   required.  A more sophisticated AMI network may also be constructed
   into the tree topology which is depicted in [RFC8036].  A tree
   topology is suitable for AMI scenarios that require large coverage
   but low density, e.g. the deployment of smart meters in rural areas.
   RPL is suitable for maintenance of a tree topology in which there is
   no need for communication directly between PAN devices.







Hou, et al.              Expires January 2, 2019               [Page 13]


Internet-Draft                IPv6 over PLC                    July 2018


                          PAN Device
                               \                   +---------
                  PAN Device    \                 /
                       \         \               +
                        \         \              |
                    PAN Device -- PCO ===========+  Internet
                        /         /              |
                       /         /               +
      PAN Device---PAN Device   /                 \
                               /                   +---------
              PAN Device---PAN Device

            <------------------------->
            PLC subnet (IPv6 over PLC)

           Figure 8: PLC Tree Network connected to the Internet

   Mesh networking in PLC is of great potential applications and has
   been studied for several years.  By connecting all nodes with their
   neighbors in communication range (see Figure 9), mesh topology
   dramatically enhances the communication efficiency and thus expands
   the size of PLC networks.  A simple use case is the smart home
   scenario where the ON/OFF state of air conditioning is controlled by
   the state of home lights (ON/OFF) and doors (OPEN/CLOSE).  AODV-RPL
   enables direct PAN device to PAN devices (without being obliged to
   transmit frames through the PCO).  This significantly improves
   performance in typical use cases, like charging station to electric
   vehicle (EV) communications.

                PAN Device---PAN Device
                    / \        / \                   +---------
                   /   \      /   \                 /
                  /     \    /     \               +
                 /       \  /       \              |
           PAN Device--PAN Device---PCO ===========+  Internet
                 \       /  \       /              |
                  \     /    \     /               +
                   \   /      \   /                 \
                    \ /        \ /                   +---------
                PAN Device---PAN Device

        <------------------------------->
            PLC subnet (IPv6 over PLC)

           Figure 9: PLC Mesh Network connected to the Internet






Hou, et al.              Expires January 2, 2019               [Page 14]


Internet-Draft                IPv6 over PLC                    July 2018


6.  IANA Considerations

   There are no IANA considerations related to this document.

7.  Security Consideration

   Due to the high accessibility of power grid, PLC might be susceptible
   to eavesdropping within its communication coverage, e.g. one
   apartment tenant may have the chance to monitor the other smart
   meters in the same apartment building.  For security consideration,
   link layer security is guaranteed in every PLC technology.

   IP addresses may be used to track devices on the Internet; such
   devices can in turn be linked to individuals and their activities.
   Depending on the application and the actual use pattern, this may be
   undesirable.  To impede tracking, globally unique and non-changing
   characteristics of IP addresses should be avoided, e.g., by
   frequently changing the global prefix and avoiding unique link-layer
   derived IIDs in addresses.  [RFC3315], [RFC3972], [RFC4941],
   [RFC5535], [RFC7217], and [RFC8065] provide valuable information for
   IID formation with improved privacy, and are RECOMMENDED for IPv6
   networks.

8.  Acknowledgements

   We gratefully acknowledge suggestions from the members of the IETF
   6lo working group.  Great thanks to Samita Chakrabarti and Gabriel
   Montenegro for their feedback and support in connecting the IEEE and
   ITU-T sides.  Authors thank Scott Mansfield, Ralph Droms, Pat Kinney
   for their guidance in the liaison process.  Authors wish to thank
   Stefano Galli, Thierry Lys, Yizhou Li and Yuefeng Wu for their
   valuable comments and contributions.

9.  References

9.1.  Normative References

   [I-D.ietf-6lo-rfc6775-update]
              Thubert, P., Nordmark, E., Chakrabarti, S., and C.
              Perkins, "Registration Extensions for 6LoWPAN Neighbor
              Discovery", draft-ietf-6lo-rfc6775-update-21 (work in
              progress), June 2018.

   [I-D.ietf-roll-aodv-rpl]
              Anamalamudi, S., Zhang, M., Sangi, A., Perkins, C., Anand,
              S., and B. Liu, "Asymmetric AODV-P2P-RPL in Low-Power and
              Lossy Networks (LLNs)", draft-ietf-roll-aodv-rpl-03 (work
              in progress), March 2018.



Hou, et al.              Expires January 2, 2019               [Page 15]


Internet-Draft                IPv6 over PLC                    July 2018


   [IEEE_1901.1]
              IEEE-SA Standards Board, "Standard for Medium Frequency
              (less than 15 MHz) Power Line Communications for Smart
              Grid Applications", IEEE 1901.1, May 2018,
              <http://sites.ieee.org/sagroups-1901-1>.

   [IEEE_1901.2]
              IEEE-SA Standards Board, "IEEE Standard for Low-Frequency
              (less than 500 kHz) Narrowband Power Line Communications
              for Smart Grid Applications", IEEE 1901.2, October 2013,
              <https://standards.ieee.org/findstds/
              standard/1901.2-2013.html>.

   [ITU-T_G.9903]
              International Telecommunication Union, "Narrowband
              orthogonal frequency division multiplexing power line
              communication transceivers for G3-PLC networks",
              ITU-T G.9903, February 2014,
              <https://www.itu.int/rec/T-REC-G.9903>.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/info/rfc2119>.

   [RFC2464]  Crawford, M., "Transmission of IPv6 Packets over Ethernet
              Networks", RFC 2464, DOI 10.17487/RFC2464, December 1998,
              <https://www.rfc-editor.org/info/rfc2464>.

   [RFC4861]  Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
              "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,
              DOI 10.17487/RFC4861, September 2007,
              <https://www.rfc-editor.org/info/rfc4861>.

   [RFC4944]  Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler,
              "Transmission of IPv6 Packets over IEEE 802.15.4
              Networks", RFC 4944, DOI 10.17487/RFC4944, September 2007,
              <https://www.rfc-editor.org/info/rfc4944>.

   [RFC6282]  Hui, J., Ed. and P. Thubert, "Compression Format for IPv6
              Datagrams over IEEE 802.15.4-Based Networks", RFC 6282,
              DOI 10.17487/RFC6282, September 2011,
              <https://www.rfc-editor.org/info/rfc6282>.








Hou, et al.              Expires January 2, 2019               [Page 16]


Internet-Draft                IPv6 over PLC                    July 2018


   [RFC6550]  Winter, T., Ed., Thubert, P., Ed., Brandt, A., Hui, J.,
              Kelsey, R., Levis, P., Pister, K., Struik, R., Vasseur,
              JP., and R. Alexander, "RPL: IPv6 Routing Protocol for
              Low-Power and Lossy Networks", RFC 6550,
              DOI 10.17487/RFC6550, March 2012,
              <https://www.rfc-editor.org/info/rfc6550>.

   [RFC6775]  Shelby, Z., Ed., Chakrabarti, S., Nordmark, E., and C.
              Bormann, "Neighbor Discovery Optimization for IPv6 over
              Low-Power Wireless Personal Area Networks (6LoWPANs)",
              RFC 6775, DOI 10.17487/RFC6775, November 2012,
              <https://www.rfc-editor.org/info/rfc6775>.

9.2.  Informative References

   [I-D.popa-6lo-6loplc-ipv6-over-ieee19012-networks]
              Popa, D. and J. Hui, "6LoPLC: Transmission of IPv6 Packets
              over IEEE 1901.2 Narrowband Powerline Communication
              Networks", draft-popa-6lo-6loplc-ipv6-over-
              ieee19012-networks-00 (work in progress), March 2014.

   [IEEE_1901.2a]
              IEEE-SA Standards Board, "IEEE Standard for Low-Frequency
              (less than 500 kHz) Narrowband Power Line Communications
              for Smart Grid Applications - Amendment 1", IEEE 1901.2a,
              September 2015, <https://standards.ieee.org/findstds/
              standard/1901.2a-2015.html>.

   [RFC3315]  Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins,
              C., and M. Carney, "Dynamic Host Configuration Protocol
              for IPv6 (DHCPv6)", RFC 3315, DOI 10.17487/RFC3315, July
              2003, <https://www.rfc-editor.org/info/rfc3315>.

   [RFC3972]  Aura, T., "Cryptographically Generated Addresses (CGA)",
              RFC 3972, DOI 10.17487/RFC3972, March 2005,
              <https://www.rfc-editor.org/info/rfc3972>.

   [RFC4291]  Hinden, R. and S. Deering, "IP Version 6 Addressing
              Architecture", RFC 4291, DOI 10.17487/RFC4291, February
              2006, <https://www.rfc-editor.org/info/rfc4291>.

   [RFC4429]  Moore, N., "Optimistic Duplicate Address Detection (DAD)
              for IPv6", RFC 4429, DOI 10.17487/RFC4429, April 2006,
              <https://www.rfc-editor.org/info/rfc4429>.







Hou, et al.              Expires January 2, 2019               [Page 17]


Internet-Draft                IPv6 over PLC                    July 2018


   [RFC4941]  Narten, T., Draves, R., and S. Krishnan, "Privacy
              Extensions for Stateless Address Autoconfiguration in
              IPv6", RFC 4941, DOI 10.17487/RFC4941, September 2007,
              <https://www.rfc-editor.org/info/rfc4941>.

   [RFC5535]  Bagnulo, M., "Hash-Based Addresses (HBA)", RFC 5535,
              DOI 10.17487/RFC5535, June 2009,
              <https://www.rfc-editor.org/info/rfc5535>.

   [RFC7217]  Gont, F., "A Method for Generating Semantically Opaque
              Interface Identifiers with IPv6 Stateless Address
              Autoconfiguration (SLAAC)", RFC 7217,
              DOI 10.17487/RFC7217, April 2014,
              <https://www.rfc-editor.org/info/rfc7217>.

   [RFC8036]  Cam-Winget, N., Ed., Hui, J., and D. Popa, "Applicability
              Statement for the Routing Protocol for Low-Power and Lossy
              Networks (RPL) in Advanced Metering Infrastructure (AMI)
              Networks", RFC 8036, DOI 10.17487/RFC8036, January 2017,
              <https://www.rfc-editor.org/info/rfc8036>.

   [RFC8065]  Thaler, D., "Privacy Considerations for IPv6 Adaptation-
              Layer Mechanisms", RFC 8065, DOI 10.17487/RFC8065,
              February 2017, <https://www.rfc-editor.org/info/rfc8065>.

   [RFC8066]  Chakrabarti, S., Montenegro, G., Droms, R., and J.
              Woodyatt, "IPv6 over Low-Power Wireless Personal Area
              Network (6LoWPAN) ESC Dispatch Code Points and
              Guidelines", RFC 8066, DOI 10.17487/RFC8066, February
              2017, <https://www.rfc-editor.org/info/rfc8066>.

Authors' Addresses

   Jianqiang Hou
   Huawei Technologies
   101 Software Avenue,
   Nanjing 210012
   China

   Email: houjianqiang@huawei.com











Hou, et al.              Expires January 2, 2019               [Page 18]


Internet-Draft                IPv6 over PLC                    July 2018


   Bing Liu
   Huawei Technologies
   No. 156 Beiqing Rd. Haidian District,
   Beijing 100095
   China

   Email: remy.liubing@huawei.com


   Yong-Geun Hong
   Electronics and Telecommunications Research Institute
   161 Gajeong-Dong Yuseung-Gu
   Daejeon 305-700
   Korea

   Email: yghong@etri.re.kr


   Xiaojun Tang
   State Grid Electric Power Research Institute
   19 Chengxin Avenue
   Nanjing 211106
   China

   Email: itc@sgepri.sgcc.com.cn


   Charles E. Perkins
   Futurewei
   2330 Central Expressway
   Santa Clara  95050
   United States of America

   Email: charliep@computer.org

















Hou, et al.              Expires January 2, 2019               [Page 19]

Html markup produced by rfcmarkup 1.127, available from https://tools.ietf.org/tools/rfcmarkup/