IPv6 over Networks of Resource-constrained Nodes (6lo) WG
Internet Engineering Task Force (IETF)                         A. Brandt
Internet-Draft
Request for Comments: 7428                                      J. Buron
Intended status:
Category: Standards Track                                  Sigma Designs
Expires: May 3,
ISSN: 2070-1721                                             January 2015                                    October 30, 2014

        Transmission of IPv6 packets Packets over ITU-T G.9959 Networks
                       draft-ietf-6lo-lowpanz-08

Abstract

   This document describes the frame format for transmission of IPv6
   packets and as well as a method of forming IPv6 link-local addresses and
   statelessly autoconfigured IPv6 addresses on ITU-T G.9959 networks.

Requirements Language

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

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 an Internet Standards Track document.

   This document is a product of the Internet Engineering Task Force
   (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list  It represents the consensus of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid the IETF community.  It has
   received public review and has been approved for a maximum publication by the
   Internet Engineering Steering Group (IESG).  Further information on
   Internet Standards is available in Section 2 of RFC 5741.

   Information about the current status of six months this document, any errata,
   and how to provide feedback on it may be updated, replaced, or obsoleted by other documents obtained 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 May 3, 2015.
   http://www.rfc-editor.org/info/rfc7428.

Copyright Notice

   Copyright (c) 2014 2015 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
   (http://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
      1.1. Terms used  . . . . . . . . . . . . . . . . . . . . . . .   3 Used .................................................3
      1.2. Requirements Language ......................................4
   2. G.9959 parameters Parameters to use Use for IPv6 transport . . . . . . . . .   5 Transport .....................5
      2.1. Addressing mode . . . . . . . . . . . . . . . . . . . . .   5 Mode ............................................5
      2.2. IPv6 Multicast support  . . . . . . . . . . . . . . . . .   6 Support .....................................6
      2.3. G.9959 MAC PDU size Size and IPv6 MTU  . . . . . . . . . . . .   6 ...........................6
      2.4. Transmission status indications . . . . . . . . . . . . .   7 Status Indications ............................7
      2.5. Transmission security . . . . . . . . . . . . . . . . . .   7 Security ......................................7
   3. 6LoWPAN Adaptation Layer and Frame Format . . . . . . . . . .   7 .......................7
      3.1. Dispatch Header . . . . . . . . . . . . . . . . . . . . .   8 ............................................8
   4. 6LoWPAN addressing  . . . . . . . . . . . . . . . . . . . . .   9 Addressing ..............................................9
      4.1. Stateless Address Autoconfiguration of routable Routable IPv6
           addresses . . . . . . . . . . . . . . . . . . . . . . . .   9
           Addresses ..................................................9
      4.2. IPv6 Link Local Link-Local Address . . . . . . . . . . . . . . . . .   9 ...................................10
      4.3. Unicast Address Mapping . . . . . . . . . . . . . . . . .  10 ...................................10
      4.4. On the use Use of Neighbor Discovery technologies . . . . . .  10 Technologies .............11
           4.4.1. Prefix and CID management (Route-over)  . . . . . . .  11 Management (Route-Over) .............11
           4.4.2. Prefix and CID management (Mesh-under)  . . . . . . .  11 Management (Mesh-Under) .............11
   5. Header Compression  . . . . . . . . . . . . . . . . . . . . .  12 .............................................12
   6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  13
   7. Security Considerations . . . . . . . . . . . . . . . . . . .  13
   8. ........................................13
   7. Privacy Considerations  . . . . . . . . . . . . . . . . . . .  13
   9.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .  14
   10. .........................................14
   8. References  . . . . . . . . . . . . . . . . . . . . . . . . .  14
     10.1. .....................................................14
      8.1. Normative References . . . . . . . . . . . . . . . . . .  14
     10.2. ......................................14
      8.2. Informative References . . . . . . . . . . . . . . . . .  15 ....................................16
   Appendix A. G.9959 6LoWPAN datagram example  . . . . . . . . . .  16
   Appendix B.  Change Log . . . . . . . . . . . . . . . . . . . . .  20
     B.1.  Changes since -00 . . . . . . . . . . . . . . . . . . . .  20
     B.2.  Changes since -01 . . . . . . . . . . . . . . . . . . . .  20
     B.3.  Changes since -02 . . . . . . . . . . . . . . . . . . . .  21
     B.4.  Changes since -03 . . . . . . . . . . . . . . . . . . . .  21
     B.5.  Changes since -04 . . . . . . . . . . . . . . . . . . . .  22
     B.6.  Changes since -05 . . . . . . . . . . . . . . . . . . . .  22
     B.7.  Changes since -06 . . . . . . . . . . . . . . . . . . . .  22
     B.8.  Changes since -07 . . . . . . . . . . . . . . . . . . . .  22 Datagram Example .......................17
   Acknowledgements ..................................................21
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  23 ................................................21

1.  Introduction

   The ITU-T G.9959 recommendation [G.9959] targets low-power Personal
   Area Networks (PANs).  This document defines the frame format for
   transmission of IPv6 [RFC2460] packets as well as the formation of
   IPv6 link-local addresses and statelessly autoconfigured IPv6
   addresses on G.9959 networks.

   The general approach is to adapt elements of [RFC4944] to G.9959
   networks.  G.9959 provides a Segmentation and Reassembly (SAR) layer
   for transmission of datagrams larger than the G.9959 MAC PDU. Media Access
   Control Protocol Data Unit (MAC PDU).

   [RFC6775] updates [RFC4944] by specifying 6LoWPAN IPv6 over Low-Power
   Wireless Personal Area Network (6LoWPAN) optimizations for IPv6
   Neighbor Discovery (ND) (originally defined by [RFC4861]).  This
   document limits the use of [RFC6775] to prefix and Context ID
   assignment.  An IID Interface Identifier (IID) may be constructed from a
   G.9959 link-layer address, leading to a "link-layer-derived IPv6
   address".  If using that method, Duplicate Address Detection (DAD) is
   not needed.  Alternatively, IPv6 addresses may be assigned centrally
   via DHCP, leading to a "non-link-layer-derived IPv6 address".
   Address registration is only needed in certain cases.

   In addition to IPv6 application communication, the frame format
   defined in this document may be used by IPv6 routing protocols such
   as RPL the Routing Protocol for Low-Power and Lossy Networks (RPL)
   [RFC6550] or P2P-RPL Reactive Discovery of Point-to-Point Routes in Low-Power
   and Lossy Networks (P2P-RPL) [RFC6997] to implement IPv6 routing over
   G.9959 networks.

   The encapsulation frame defined by this specification may optionally
   be transported via mesh routing below the 6LoWPAN layer.  Mesh-under
   and route-over routing protocol specifications are out of scope of for
   this document.

1.1.  Terms used Used

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

   ABR: Authoritative 6LBR ([RFC6775]) 6LoWPAN Border Router (Authoritative 6LBR)
      [RFC6775]

   Ack: Acknowedgement Acknowledgement

   AES: Advanced Encryption Scheme Standard

   CID: Context Identifier ([RFC6775]) [RFC6775]

   DAD: Duplicate Address Detection ([RFC6775]) [RFC6775]

   DHCPv6: Dynamic Host Configuration Protocol for IPv6 ([RFC3315]) [RFC3315]

   EUI-64: Extended Unique Identifier ([EUI64]) [EUI64]

   G.9959: Short range, range narrow-band digital radiocommunication
      transceiver ([G.9959]) [G.9959]

   GHC: Generic Header Compression ([RFC_TBD_GHC]) [RFC7400]

   HomeID: G.9959 Link-Layer Network Identifier

   IID: Interface IDentifier Identifier
   Link-layer-derived address: IPv6 Address address constructed on the basis of link
   layer
      link-layer address information

   MAC: Media Access Control

   Mesh-under: Forwarding via mesh routing below the 6LoWPAN layer

   MTU: Maximum Transmission Unit

   ND: Neighbor discovery ([RFC4861], [RFC6775]) Discovery [RFC4861] [RFC6775]

   NodeID: G.9959 Link-Layer Node Identifier

   Non-link-layer-derived address: IPv6 Address address assigned by a managed
      process, e.g.  DHCPv6.

   NVM: Non-volatile Memory e.g., DHCPv6

   P2P-RPL: Reactive Discovery of Point-to-Point Routes in Low-Power and
      Lossy Networks ([RFC6997]) [RFC6997]

   PAN: Personal Area Network

   PDU: Protocol Data Unit

   PHY: Physical Layer

   RA: Router Advertisement ([RFC4861], [RFC6775]) [RFC4861] [RFC6775]

   Route-over: Forwarding via IP routing above the 6LoWPAN layer

   RPL: IPv6 Routing Protocol for Low-Power and Lossy Networks
   ([RFC6550]) [RFC6550]

   SAR: G.9959 Segmentation And and Reassembly

   ULA: Unique Local Address [RFC4193]

1.2.  Requirements Language

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

2.  G.9959 parameters Parameters to use Use for IPv6 transport Transport

   This chapter section outlines properties applying to the PHY and MAC layers
   of G.9959 and how to use these for IPv6 transport.

2.1.  Addressing mode Mode

   G.9959 defines how a unique 32-bit HomeID network identifier is
   assigned by a network controller and how an 8-bit NodeID host
   identifier is allocated to each node.  NodeIDs are unique within the
   network identified by the HomeID.  The G.9959 HomeID represents an
   IPv6 subnet which that is identified by one or more IPv6 prefixes.

   An IPv6 host MUST construct its link-local IPv6 address from the
   link-layer-derived IID in order to facilitate IP header compression
   as described in [RFC6282].

   A node interface MAY support the M flag of the RA message for the
   construction of routable IPv6 addresses.  A cost optimized cost-optimized node
   implementation may save memory by skipping support for the M flag.
   The M flag MUST be interpreted as defined in Figure 1.

    +--------+--------+---------------------------------------------+
    | M Flag flag | M flag |  Required node behavior                     |
    | support| value  |                                             |
    +--------+--------+---------------------------------------------+
    | No     |(ignore)| Node MUST use link-layer-derived addressing |
    +--------+--------+---------------------------------------------+
    | Yes    |    0   | Node MUST use link-layer-derived addressing |
    |        +--------+---------------------------------------------+
    |        |    1   | Node MUST use DHCPv6 based addressing DHCPv6-based addressing, and  |
    |        |        | Node node MUST comply fully with [RFC6775]       |
    +--------+--------+---------------------------------------------+

              Figure 1: RA M flag support Flag Support and interpretation Interpretation

   A node that uses DHCPv6 based DHCPv6-based addressing MUST comply fully with the
   text of [RFC6775].

   If DHCPv6 based DHCPv6-based addressing is used, the DHCPv6 client must use a DUID
   DHCPv6 Unique Identifier (DUID) of type DUID-UUID, as described in
   [RFC6355].  The UUID Universally Unique Identifier (UUID) used in the
   DUID-UUID must be generated as specified in [RFC4122], section Section 4.5,
   starting at the second third paragraph in that section (the 47-bit random
   number-based UUID).  The DUID must be stored persistently by the node
   as specified in section Section 3 of [RFC6355].

   A word of caution: since HomeIDs and NodeIDs are handed out by a
   network controller function during inclusion, identifier validity and
   uniqueness is are limited by the lifetime of the network membership.
   This can be cut short by a mishap occurring to at the network
   controller.  Having a single point of failure at the network
   controller suggests that high-reliability network deployments may
   benefit from a redundant network controller function.

   This warning applies to link-layer-derived addressing as well as to
   non-link-layer-derived addressing deployments.

2.2.  IPv6 Multicast support Support

   [RFC3819] recommends that IP subnetworks support (subnet-wide)
   multicast.  G.9959 supports direct-range IPv6 multicast multicast, while subnet-
   wide
   subnet-wide multicast is not supported natively by G.9959.  Subnet-wide  Subnet-
   wide multicast may be provided by an IP routing protocol or a mesh
   routing protocol operating below the 6LoWPAN layer.  Routing protocol
   specifications are out of scope of for this document.

   IPv6 multicast packets MUST be carried via G.9959 broadcast.

   As per [G.9959], this is accomplished as follows:

   1.  The destination HomeID of the G.9959 MAC PDU MUST be the HomeID
       of the network network.

   2.  The destination NodeID of the G.9959 MAC PDU MUST be the
       broadcast NodeID (0xff) (0xff).

   G.9959 broadcast MAC PDUs are only intercepted by nodes within the
   network identified by the HomeID.

2.3.  G.9959 MAC PDU size Size and IPv6 MTU

   IPv6 packets MUST be transmitted using G.9959 transmission profile R3
   or higher.

   [RFC2460] specifies that any link that cannot convey a 1280-octet
   packet in one piece, piece must provide link-specific fragmentation and
   reassembly at a layer below IPv6.

   G.9959 provides Segmentation And Reassembly segmentation and reassembly for payloads up to
   1350 octets.  IPv6 Header Compression header compression [RFC6282] improves the chances
   that a short IPv6 packet can fit into a single G.9959 frame.
   Therefore, Section 3 of this document specifies that [RFC6282] MUST
   be supported.  With the mandatory link-layer security enabled, a
   G.9959 R3 MAC PDU may accommodate 6LoWPAN datagrams of up to
   130 octets without triggering G.9959 Segmentation segmentation and Reassembly (SAR). reassembly.
   Longer 6LoWPAN datagrams will lead to the transmission of multiple
   G.9959 PDUs.

2.4.  Transmission status indications Status Indications

   The G.9959 MAC layer provides native acknowledgement and
   retransmission of MAC PDUs.  The G.9959 SAR layer does the same for
   larger datagrams.  A mesh routing layer may provide a similar feature
   for routed communication.  An IPv6 routing stack communicating over
   G.9959 may utilize link-layer status indications such as delivery
   confirmation and Ack timeout from the MAC layer.

2.5.  Transmission security Security

   Implementations claiming conformance with this document MUST enable
   G.9959 shared network key security.

   The shared network key is intended to address security requirements
   in the home at the normal level of security requirements level. requirements.  For
   applications with high or very high requirements on for confidentiality
   and/or integrity, additional application layer application-layer security measures for
   end-to-end authentication and encryption may need to be applied.
   (The availability of the network relies on the security properties of
   the network key in any case) case.)

3.  6LoWPAN Adaptation Layer and Frame Format

   The 6LoWPAN encapsulation formats defined in this chapter section are carried
   as payload in the G.9959 MAC PDU.  IPv6 header compression [RFC6282]
   MUST be supported by implementations of this specification.  Further,
   implementations MAY support Generic Header Compression (GHC)
   [RFC_TBD_GHC].
   [RFC7400].  A node implementing [RFC_TBD_GHC] [RFC7400] MUST probe its peers for
   GHC support before applying GHC compression. GHC.

   All 6LoWPAN datagrams transported over G.9959 are prefixed by a
   6LoWPAN encapsulation header stack.  The 6LoWPAN payload follows this
   encapsulation header stack.  Each header in the header stack contains
   a header type followed by zero or more header fields.  An IPv6 header
   stack may contain, in the following order, addressing, hop-by-hop
   options, routing, fragmentation, destination options, and finally and, finally,
   payload [RFC2460].  The 6LoWPAN header format is structured the same
   way.  Currently  Currently, only one payload option is defined for the G.9959
   6LoWPAN header format.

   The definition of 6LoWPAN headers consists of the dispatch value, the
   definition of the header fields that follow, and their ordering
   constraints relative to all other headers.  Although the header stack
   structure provides a mechanism to address future demands on the
   6LoWPAN adaptation layer, it is not intended to provide general general-
   purpose extensibility.

   An example of a complete G.9959 6LoWPAN datagram can be found in
   Appendix A.

3.1.  Dispatch Header

   The dispatch header Dispatch Header is shown below:

     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
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    | 6LoWPAN CmdCls|   Dispatch    |  Type-specific header         |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                    Figure 2: Dispatch Type and Header

   6LoWPAN CmdCls: 6LoWPAN Command Class identifier.  This field MUST
      carry the value 0x4F [G.9959].  The value is assigned by the ITU-T
      and specifies that the following bits are a 6LoWPAN encapsulated
      datagram.  6LoWPAN protocols MUST ignore the G.9959 frame if the
      6LoWPAN Command Class identifier deviates from 0x4F.

   Dispatch: Identifies the header type immediately following the
      Dispatch Header.

   Type-specific header: A header determined by the Dispatch Header.

   The dispatch value may be treated as an unstructured namespace.  Only
   a few symbols are required to represent current 6LoWPAN
   functionality.  Although some additional savings could be achieved by
   encoding additional functionality into the dispatch byte, these
   measures would tend to constrain the ability to address future
   alternatives.

   Dispatch values used in this specification are compatible with the
   dispatch values defined by [RFC4944] and [RFC6282].

   +------------+------------------------------------------+-----------+

              +------------+--------------------+-----------+
              | Pattern    | Header Type        | Reference |
   +------------+------------------------------------------+-----------+
              +------------+--------------------+-----------+
              | 01  1xxxxx | 6LoWPAN_IPHC - Compressed IPv6 Addresses       | [RFC6282] |
   +------------+------------------------------------------+-----------+
    All other Dispatch
              +------------+--------------------+-----------+

              Other IANA-assigned 6LoWPAN dispatch values are unassigned in do not
              apply to this document.

                         Figure 3: Dispatch values Values

   6LoWPAN_IPHC: IPv6 Header Compression.  Refer to [RFC6282].

4.  6LoWPAN addressing Addressing

   IPv6 addresses may be autoconfigured from IIDs which that may again be
   constructed from link-layer address information to save memory in
   devices and to facilitate efficient IP header compression as per
   [RFC6282].  Link-layer-derived addresses have a static nature and may
   involuntarily expose private usage data on public networks.  Refer to
   Section 8. 7.

   A NodeID is mapped into an IEEE EUI-64 identifier as follows:

                        IID = 0000:00ff:fe00:YYXX

                 Figure 4: Constructing a compressible Compressible IID

   where XX carries the G.9959 NodeID and YY is a one byte 1-byte value chosen by
   the individual node.  The default YY value MUST be zero.  A node MAY
   use other values of YY other than zero to form additional IIDs in order to
   instantiate multiple IPv6 interfaces.  The YY value MUST be ignored
   when computing the corresponding NodeID (the XX value) from an IID.

   The method of constructing IIDs from the link-layer address obviously
   does not support addresses assigned or constructed by other means.  A
   node MUST NOT compute the NodeID from the IID if the first 6 bytes of
   the IID do not comply with the format defined in Figure 4.  In that
   case, the address resolution mechanisms of RFC 6775 [RFC6775] apply.

4.1.  Stateless Address Autoconfiguration of routable Routable IPv6 addresses Addresses

   The IID defined above MUST be used whether autoconfiguring a ULA IPv6
   address [RFC4193] or a globally routable IPv6 address [RFC3587] in
   G.9959 subnets.

4.2.  IPv6 Link Local Link-Local Address

   The IPv6 link-local address [RFC4291] for a G.9959 interface is
   formed by appending the IID defined above to the IPv6 link local link-local
   prefix FE80::/64. fe80::/64.

   The "Universal/Local" (U/L) bit MUST be set to zero in keeping with
   the fact that this is not a globally unique value [EUI64].

   The resulting link local link-local address is formed as follows:

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

                     Figure 5: IPv6 Link Local Link-Local Address

4.3.  Unicast Address Mapping

   The address resolution procedure for mapping IPv6 unicast addresses
   into G.9959 link-layer addresses follows the general description in
   Section 7.2 of [RFC4861].  The Source/Target Link-layer Address
   option MUST have the following form when the link layer is G.9959.

                      0                   1
                      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
                     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                     |     Type      |    Length=1   |
                     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                     |     0x00      |    NodeID     |
                     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                     |            Padding            |
                     +-                             -+
                     |          (All zeros)          |
                     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                  Figure 6: IPv6 Unicast Address Mapping

   Option fields:

   Type:  The value 1 signifies the Source Link-layer address.  The
      value 2 signifies the Destination Link-layer address.

   Length:  This is the length of this option (including the type Type and
   length
      Length fields) in units of 8 octets.  The value of this field is
      always 1 for G.9959 NodeIDs.

   NodeID:  This is the G.9959 NodeID to which the actual interface
      currently
   responds to. responds.  The link-layer address may change if the
      interface joins another network at a later time.

4.4.  On the use Use of Neighbor Discovery technologies Technologies

   [RFC4861] specifies how IPv6 nodes may resolve link layer link-layer addresses
   from IPv6 addresses via the use of link-local IPv6 multicast.
   [RFC6775] is an optimization of [RFC4861], specifically targeting
   6LoWPAN networks.  [RFC6775] defines how a 6LoWPAN node may register
   IPv6 addresses with an authoritative border router (ABR).  Mesh-under
   networks MUST NOT use [RFC6775] address registration.  However,
   [RFC6775] address registration MUST be used if the first 6 bytes of
   the IID do not comply with the format defined in Figure 3. 4.

4.4.1.  Prefix and CID management (Route-over) Management (Route-Over)

   In route-over environments, IPv6 hosts MUST use [RFC6775] address
   registration.  A node implementation for route-over operation MAY use
   RFC6775
   [RFC6775] mechanisms for obtaining IPv6 prefixes and corresponding
   header compression context information [RFC6282].  RFC6775 Route-over  [RFC6775] route-
   over requirements apply with no modifications.

4.4.2.  Prefix and CID management (Mesh-under) Management (Mesh-Under)

   An implementation for mesh-under operation MUST use [RFC6775]
   mechanisms for managing IPv6 prefixes and corresponding header
   compression context information [RFC6282].  [RFC6775] Duplicate
   Address Detection (DAD) MUST NOT be used, since the link-layer
   inclusion process of G.9959 ensures that a NodeID is unique for a
   given HomeID.

   With this exception and the specific redefinition of the RA Router
   Lifetime value 0xFFFF (refer to Section 4.4.2.3), the text of the
   following subsections is in compliance with [RFC6775].

4.4.2.1.  Prefix assignment considerations Assignment Considerations

   As stated by [RFC6775], an ABR is responsible for managing
   prefix(es).  Global routable prefixes may change over time.  It is
   RECOMMENDED that a ULA prefix is assigned to the 6LoWPAN subnet to
   facilitate stable site-local application associations based on IPv6
   addresses.  A node MAY support the M flag of the RA message.  This
   influences the way IPv6 addresses are assigned.  Refer to Section 2.1
   for details.

4.4.2.2.  Robust and efficient Efficient CID management Management

   The 6LoWPAN Context Option (6CO) is used according to [RFC6775] in an
   RA to disseminate Context IDs (CID) (CIDs) to use for compressing prefixes.
   One or more prefixes and corresponding Context IDs MUST be assigned
   during initial node inclusion.

   When updating context information, a CID may have its lifetime set to
   zero to obsolete it.  The CID MUST NOT be reused immediately; rather rather,
   the next vacant CID should be assigned.  Header compression based on
   CIDs MUST NOT be used for RA messages carrying Context Information. context information.
   An expired CID and the associated prefix MUST NOT be reset but rather
   must be retained in receive-only mode if there is no other current
   need for the CID value.  This will allow an ABR to detect if a
   sleeping node without a clock uses an expired CID CID, and in response,
   the ABR MUST return an RA with fresh Context Information context information to the
   originator.

4.4.2.3.  Infinite prefix lifetime support Prefix Lifetime Support for island-mode networks Island-Mode Networks

   Nodes MUST renew the prefix and CID according to the lifetime
   signaled by the ABR.  [RFC6775] specifies that the maximum value of
   the RA Router Lifetime field MAY be up to 0xFFFF.  This document
   further specifies that the value 0xFFFF MUST be interpreted as
   infinite lifetime.  This value MUST NOT be used by ABRs.  Its use is
   only intended for a sleeping network controller; controller -- for instance instance, a
   battery powered
   battery-powered remote control being master for a small island-mode
   network of light modules.

5.  Header Compression

   IPv6 header compression [RFC6282] MUST be implemented implemented, and
   [RFC_TBD_GHC] GHC
   [RFC7400] compression for higher layers MAY be implemented.  This
   section will simply identify substitutions that should be made when
   interpreting the text of [RFC6282] and [RFC_TBD_GHC]. [RFC7400].

   In general general, the following substitutions should be made:

   o  Replace "802.15.4" with "G.9959" "G.9959".

   o  Replace "802.15.4 short address" with "<Interface><G.9959 NodeID>"
      NodeID>".

   o  Replace "802.15.4 PAN ID" with "G.9959 HomeID" HomeID".

   When a 16-bit address is called for (i.e., an IEEE 802.15.4 "short
   address")
   address"), it MUST be formed by prepending an Interface label byte to
   the G.9959 NodeID:

                      0                   1
                      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
                     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                     |   Interface   |    NodeID     |
                     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   A transmitting node may be sending to an IPv6 destination address
   which
   that can be reconstructed from the link-layer destination address.
   If the Interface number is zero (the default value), all IPv6 address
   bytes may be elided.  Likewise, the Interface number of a fully
   elided IPv6 address (i.e. (i.e., SAM/DAM=11) may be reconstructed to the
   value zero by a receiving node.

   64 bit

   64-bit 802.15.4 address details do not apply.

6.  IANA Considerations

   This document makes no request of IANA.

   Note to RFC Editor: this section may be removed on publication as an
   RFC.

7.  Security Considerations

   The method of derivation of Interface Identifiers from 8-bit NodeIDs
   preserves uniqueness within the network.  However, there is no
   protection from duplication through forgery.  Neighbor Discovery in
   G.9959 links may be susceptible to threats as detailed in [RFC3756].
   G.9959 networks may feature mesh routing.  This implies additional
   threats due to ad hoc routing as per [KW03].  G.9959 provides
   capability for link-layer security.  G.9959 nodes MUST use link-layer
   security with a shared key.  Doing so will alleviate the majority of
   threats stated above.  A sizeable sizable portion of G.9959 devices is
   expected to always communicate within their PAN (i.e., within their
   subnet, in IPv6 terms).  In response to cost and power consumption
   considerations, these devices will typically implement the minimum
   set of features necessary.  Accordingly, security for such devices
   may rely on the mechanisms defined at the link layer by G.9959.
   G.9959 relies on the Advanced Encryption Standard (AES) for
   authentication and encryption of G.9959 frames and further employs
   challenge-response handshaking to prevent replay attacks.

   It is also expected that some G.9959 devices (e.g. (e.g., billing and/or
   safety critical
   safety-critical products) will implement coordination or integration
   functions.  These may communicate regularly with IPv6 peers outside
   the subnet.  Such IPv6 devices are expected to secure their end-to-
   end communications with standard security mechanisms (e.g., IPsec,
   TLS, etc).

8.
   Transport Layer Security (TLS), etc.).

7.  Privacy Considerations

   IP addresses may be used to track devices on the Internet, which Internet; such
   devices can in turn can 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. e.g., by
   frequently changing the global prefix and avoiding unique link-layer-derived link-layer-
   derived IIDs in addresses.

   Some link layers use a 48-bit or a 64-bit link layer link-layer address which that
   uniquely identifies the node on a global scale scale, regardless of global
   prefix changes.  The risk of exposing a G.9959 device from its link-
   layer-derived
   link-layer-derived IID is limited because of the short 8-bit link layer
   link-layer address.

   While intended for central address management, DHCPv6 address
   assignment also decouples the IPv6 address from the link layer link-layer
   address.  Addresses may be made dynamic by the use of a short DHCP
   lease period and an assignment policy which that makes the DHCP server hand
   out a fresh IP address every time.  For enhanced privacy, the
   DHCP assigned
   DHCP-assigned addresses should be logged only for the duration of the
   lease
   lease, provided the implementation also allows logging for longer
   durations as per the operational policies.

   It should be noted that privacy and frequently changing address
   assignment comes
   assignments come at a cost.  Non-link-layer-derived IIDs require the
   use of address registration and further, registration.  Further, non-link-layer-derived IIDs
   cannot be compressed, which compressed; this leads to longer datagrams and increased
   link layer
   link-layer segmentation.  Finally, frequent prefix changes
   necessitate more Context Identifier updates, which updates; this not only leads to
   increased traffic but also may affect the battery lifetime of
   sleeping nodes.

9.  Acknowledgements

   Thanks to the authors of RFC 4944 and RFC 6282 and members of the
   IETF 6LoWPAN working group; this document borrows extensively from
   their work.  Thanks to Erez Ben-Tovim, Erik Nordmark, Kerry Lynn,
   Michael Richardson, Tommas Jess Christensen for useful comments.
   Thanks to Carsten Bormann for extensive feedback which improved this
   document significantly.  Thanks to Brian Haberman for pointing out
   unclear details.

10.

8.  References

10.1.

8.1.  Normative References

   [G.9959]   "G.9959 (02/12) + G.9959 Amendment 1 (10/13): Short range,   International Telecommunication Union, "Short range
              narrow-band digital radiocommunication transceivers",
              February 2012. transceivers - PHY
              and MAC layer specifications", ITU-T Recommendation
              G.9959, January 2015,
              <http://www.itu.int/rec/T-REC-G.9959>.

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

   [RFC2460]  Deering, S. and R. Hinden, "Internet Protocol, Version 6
              (IPv6) Specification", RFC 2460, December 1998. 1998,
              <http://www.rfc-editor.org/info/rfc2460>.

   [RFC4122]  Leach, P., Mealling, M., and R. Salz, "A Universally
              Unique IDentifier (UUID) URN Namespace", RFC 4122,
              July
              2005. 2005, <http://www.rfc-editor.org/info/rfc4122>.

   [RFC4193]  Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast
              Addresses", RFC 4193, October 2005. 2005,
              <http://www.rfc-editor.org/info/rfc4193>.

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

   [RFC4861]  Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
              "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,
              September 2007. 2007, <http://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, September 2007. 2007,
              <http://www.rfc-editor.org/info/rfc4944>.

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

   [RFC6355]  Narten, T. and J. Johnson, "Definition of the UUID-Based
              DHCPv6 Unique Identifier (DUID-UUID)", RFC 6355,
              August
              2011. 2011, <http://www.rfc-editor.org/info/rfc6355>.

   [RFC6775]  Shelby, Z., Chakrabarti, S., Nordmark, E., and C. Bormann,
              "Neighbor Discovery Optimization for IPv6 over Low-Power
              Wireless Personal Area Networks (6LoWPANs)", RFC 6775,
              November 2012.

   [RFC_TBD_GHC]
              "draft-ietf-6lo-ghc: 6LoWPAN 2012, <http://www.rfc-editor.org/info/rfc6775>.

   [RFC7400]  Bormann, C., "6LoWPAN-GHC: Generic Header Compression of
              Headers and Header-like Payloads", September 2014.

10.2. for
              IPv6 over Low-Power Wireless Personal Area Networks
              (6LoWPANs)", RFC 7400, November 2014,
              <http://www.rfc-editor.org/info/rfc7400>.

8.2.  Informative References

   [EUI64]    IEEE, "GUIIDELINES FOR 64-BIT GLOBAL IDENTIFIER (EUI-64)
              REGISTRATION AUTHORITY", IEEE Std http://
              standards.ieee.org/regauth/oui/tutorials/EUI64.html, "Guidelines for 64-bit Global Identifier
              (EUI-64TM)", November 2012. 2012, <http://standards.ieee.org/
              regauth/oui/tutorials/EUI64.html>.

   [KW03]     Elsevier's AdHoc Networks Journal, ""Secure     Karlof, C. and D. Wagner, "Secure Routing in Sensor
              Networks: Attacks and Countermeasures", Elsevier Ad Hoc
              Networks Journal, Special Issue on Sensor Network
              Applications and Protocols vol Protocols, vol. 1, issues 2-3", , 2-3,
              September 2003.

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

   [RFC3587]  Hinden, R., Deering, S., and E. Nordmark, "IPv6 Global
              Unicast Address Format", RFC 3587, August 2003. 2003,
              <http://www.rfc-editor.org/info/rfc3587>.

   [RFC3756]  Nikander, P., Kempf, J., and E. Nordmark, "IPv6 Neighbor
              Discovery (ND) Trust Models and Threats", RFC 3756,
              May
              2004. 2004, <http://www.rfc-editor.org/info/rfc3756>.

   [RFC3819]  Karn, P., Bormann, C., Fairhurst, G., Grossman, D.,
              Ludwig, R., Mahdavi, J., Montenegro, G., Touch, J., and L.
              Wood, "Advice for Internet Subnetwork Designers", BCP 89,
              RFC 3819, July 2004. 2004,
              <http://www.rfc-editor.org/info/rfc3819>.

   [RFC6550]  Winter, T., Thubert, P., 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, March 2012. 2012,
              <http://www.rfc-editor.org/info/rfc6550>.

   [RFC6997]  Goyal, M., Baccelli, E., Philipp, M., Brandt, A., and J.
              Martocci, "Reactive Discovery of Point-to-Point Routes in
              Low-Power and Lossy Networks", RFC 6997, August 2013. 2013,
              <http://www.rfc-editor.org/info/rfc6997>.

Appendix A.  G.9959 6LoWPAN datagram example Datagram Example

   This example outlines each individual bit of a sample IPv6 UDP packet
   arriving to a G.9959 node from a host in the Internet via a PAN
   border router.

   In the G.9959 PAN, the complete frame has the following fields.

   G.9959:

     +------+---------+----------+---+-----+----------...
     |HomeID|SrcNodeID|FrmControl|Len|SeqNo|DestNodeID|
     +------+---------+----------+---+-----+----------+-...

   6LoWPAN:

     ...+--------------+----------------+-----------------------...
        |6LoWPAN CmdCls|6LoWPAN_IPHC Hdr|Compressed IPv6 headers|
       ...-------------+----------------+-----------------------+-...

   6LoWPAN,

   IPv6, TCP/UDP, App payload:

       ...+-------------------------+------------+-----------+
          |Uncompressed IPv6 headers|TCP/UDP/ICMP|App payload|
         ...------------------------+------------+-----------+

   The frame comes from the source IPv6 address
   2001:0db8:ac10:ef01::ff:fe00:1206.  The source prefix
   2001:0db8:ac10:ef01/64 is identified by the IPHC CID = 3.

   The frame is delivered in direct range from the gateway which that has
   source NodeID = 1.  The Interface Identifier (IID) ff:fe00:1206 is
   recognised
   recognized as a link-layer-derived address and is compressed to the
   16 bit
   16-bit value 0x1206.

   The frame is sent to the destination IPv6 address
   2001:0db8:27ef:42ca::ff:fe00:0004.  The destination prefix
   2001:0db8:27ef:42ca/64 is identified by the IPHC CID = 2.

   The Interface Identifier (IID) IID ff:fe00:0004 is recognised recognized as a link-
   layer-derived link-layer-derived address.

   Thanks to the link-layer-derived addressing rules, the sender knows
   that this is to be sent to G.9959 NodeID = 4; 4, targeting the IPv6
   interface instance number 0 (the default).

   To reach the 6LoWPAN stack of the G.9959 node, node (skipping the G.9959
   header fields) fields), the first octet must be the 6LoWPAN Command Class
   (0x4F).

        0
        0 1 2 3 4 5 6 7 8
       +-+-+-+-+-+-+-+-...
       |     0x4F      |
       +-+-+-+-+-+-+-+-+-...

   The Dispatch header Header bits '011' advertises advertise a compressed IPv6 header.

        0                   1
        0 1 2 3 4 5 6 7 8 9 0
       +-+-+-+-+-+-+-+-+-+-+-...
       |     0x4F      |0 1 1
       +-+-+-+-+-+-+-+-+-+-+-+-...

   The following bits encode the first IPv6 header fields:

   TF = '11'   : Traffic Class and Flow Label are elided. elided
   NH = '1'    : Next Header is elided
   HLIM = '10' : Hop limit is 64

         0                   1
         0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...
        |     0x4F      |0 1 1 1 1 1 1 0|
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...

   CID = '1'   : CI data follows the DAM field
   SAC = '1'   : Src addr uses stateful, context-based compression
   SAM = '10'  : Use src CID and 16 bits for link-layer-derived addr
   M = '0'     : Dest addr is not a multicast addr
   DAC = '1'   : Dest addr uses stateful, context-based compression
   DAM = '11'  : Use dest CID and dest NodeID to link-layer-derived addr

        0                   1                   2
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...
       |     0x4F      |0 1 1 1 1 1 1 0|1 1 1 0 0 1 1 1|
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...

   Address compression context identifiers:

   SCI =  0x3
   DCI =  0x2

          2           3
          4 5 6 7 8 9 0 1
      ...+-+-+-+-+-+-+-+-...
         |  0x3  |  0x2  |
        ...+-+-+-+-+-+-+-+-...

   IPv6 header fields:
   (skipping "version" field)
   (skipping "Traffic Class")
   (skipping "flow label")
   (skipping "payload length")

   IPv6 header address fields:

   SrcIP = 0x1206 : Use SCI and 16 LS least significant bits of
   link-layer-derived address

   (skipping DestIP ) - completely reconstructed from Dest dest NodeID
                        and DCI

          2           3                   4
          4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7
      ...+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...
         |  0x3  |  0x2  |     0x12      |     0x06      |
        ...+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...

   Next header Header encoding for the UDP header:

   Dispatch = '11110': Next Header dispatch code for UDP header
   C =      '0'      : 16 bit 16-bit checksum carried inline
   P =      '00'     : Both src port and dest Port port are carried in-line. in-line

          4   5
          8 9 0 1 2 3 4 5
      ...+-+-+-+-+-+-+-+-...
         |1 1 1 1 0|0|0 0|
        ...+-+-+-+-+-+-+-+-...

 UDP header fields:

 src Port port  = 0x1234
 dest port = 0x5678

     5       6                   7                   8
     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 2 3 4 5 6 7
 ...+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...
    |     0x12      |     0x34      |     0x56      |     0x78      |
   ...+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-..

 (skipping "length")
 checksum = ....  (actual checksum value depends on
                   the actual UDP payload)

                                1
        8   9                   0
        8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
    ...+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...
       |         (UDP checksum)        |
      ...+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...

 Add your own UDP payload here...

Appendix B.  Change Log

B.1.  Changes since -00

   o  Clarified that mesh-under routing may take place below the 6LoWPAN
      layer but that specific mesh-under routing protocols are not
      within

Acknowledgements

   Thanks to the scope authors of this doc.

   o  Clarified that RFC6282 IPv6 Header Compression MUST be supported.

   o  Clarified the text RFC 4944 and RFC 6282, and members of section 5.4 on the use of RFC6775 address
      registration in mesh-under networks.

   o  Split 5.4.2 into multiple paragraphs.

B.2.  Changes since -01

   o  Added
   IETF 6LoWPAN working group; this Change Log

   o  Editorial nits.

   o  Made IPv6 Header Compression mandatory.  Therefore, the Dispatch
      value "01 000001 - Uncompressed IPv6 Addresses" was removed document borrows extensively from
      figure 2.

   o  Changed SHOULD
   their work.  Thanks to MUST: An IPv6 host SHOULD construct its link-
      local IPv6 address and routable IPv6 addresses from the NodeID in
      order to facilitate IP header compression as described in
      [RFC6282].

   o  Changed SHOULD NOT to MUST NOT: Mesh-under networks MUST NOT use
      [RFC6775] address registration.

   o  Changed SHOULD NOT to MUST NOT: [RFC6775] Duplicate Address
      Detection (DAD) MUST NOT be used.

   o  Changed SHOULD NOT to MUST NOT: The CID MUST NOT be reused
      immediately;

   o  Changed SHOULD NOT to MUST NOT: An expired CID Erez Ben-Tovim, Erik Nordmark, Kerry Lynn,
   Michael Richardson, and the associated
      prefix MUST NOT be reset but rather retained in receive-only mode

   o  Changed LBR -> ABR

   o  Changed SHOULD to MUST: , the ABR MUST return an RA with fresh
      Context Information to the originator.

   o  Changed SHOULD NOT to MUST NOT: This value MUST NOT be used by
      ABRs.  Its use is only intended Tommas Jess Christensen for a sleeping network controller.

B.3.  Changes since -02

   o  Editorial nits.

   o  Moved text useful comments.
   Thanks to the right section so that it does not prohibit DAD Carsten Bormann for Route-Over deployments.

   o  Introduced RA M flag support so extensive feedback that nodes may be instructed to
      use DHCPv6 for centralized address assignment.

   o  Added example appendix: Complete G.9959 6LoWPAN datagram
      composition with CID-based header compression.

B.4.  Changes since -03

   o  Corrected error in 6LoWPAN datagram example appendix: 64 hop limit
      in comment => also 64 hop limit in actual frame format.

   o  Added section "Privacy Considerations"

B.5.  Changes since -04

   o  Text on RA M flag support was replaced with a table to improve
      clarity.

   o  Added further details to text on achieving privacy addressing with
      DHCP.

B.6.  Changes since -05

   o  Term ABR now points to Authoritative 6LBR as defined by RFC6775.

   o  Removed sentence "The G.9959 network controller function SHOULD be
      integrated in the ABR." as improved this was an implementation guideline
      with no relevance to network performance.

   o  Clarifying that network controller function redundancy is relevant
      for network deployers; not user-level application designers.

   o  Clarified that RFC2460 specifies that link layer must provide
      fragmentation if 1280 octet packets cannot be carried in one piece
      by the link layer.

   o  Clarified that the 6LoWPAN CmdCls identifier value is assigned by
      the ITU-T.

   o  Added reference to Privacy Considerations section from 6LoWPAN
      Addressing section.

   o  Introducing optional GHC header compression.

B.7.  Changes since -06

   o  Added a note to section 5, that the mapping of 802.15.4 terms to
      similar G.9959 terms applies not only to RFC6282 but also to GHC.

B.8.  Changes since -07

   o  Added a note
   document significantly.  Thanks to the Privacy considerations section on avoiding
      DHCP logging.

   o  Added requirements Brian Haberman for forming a UUID if DHCPv6 address assignment
      is used. pointing out
   unclear details.

Authors' Addresses

   Anders Brandt
   Sigma Designs
   Emdrupvej 26A, 1.
   Copenhagen O  2100
   Denmark

   Email:

   EMail: anders_brandt@sigmadesigns.com

   Jakob Buron
   Sigma Designs
   Emdrupvej 26A, 1.
   Copenhagen O  2100
   Denmark

   Email:

   EMail: jakob_buron@sigmadesigns.com