6Lo Working Group
Internet Engineering Task Force (IETF)                       P. Mariager
Internet-Draft
Request for Comments: 8105                              J. Petersen, Ed.
Intended status:
Category: Standards Track                                        RTX A/S
Expires: June 18, 2017
ISSN: 2070-1721                                                Z. Shelby
                                                                     ARM
                                                          M. Van van de Logt
                                             Gigaset Communications
                                                    Bosch Sensortec GmbH
                                                              D. Barthel
                                                             Orange Labs
                                                       December 15, 2016
                                                           February 2017

      Transmission of IPv6 Packets over DECT Digital Enhanced Cordless
            Telecommunications (DECT) Ultra Low Energy
                       draft-ietf-6lo-dect-ule-09 (ULE)

Abstract

   Digital Enhanced Cordless Telecommunications (DECT) Ultra Low Energy
   (ULE) is a low power low-power air interface technology that is defined proposed by the
   DECT Forum and is defined and specified by ETSI.

   The DECT air interface technology has been used world-wide worldwide in
   communication devices for more than 20 years, years.  It has primarily carrying been
   used to carry voice for cordless telephony but has also been deployed
   for data
   centric data-centric services.

   The

   DECT Ultra Low Energy ULE is a recent addition to the DECT interface primarily
   intended for low-bandwidth, low-power applications such as sensor
   devices, smart meters, home automation automation, etc.  As the DECT Ultra
   Low Energy ULE
   interface inherits many of the capabilities from DECT, it benefits
   from long range, interference free operation, world wide operation that is long-range and interence-free, worldwide-
   reserved frequency band, low silicon prices prices, and maturity.  There is
   an added value in the ability to communicate with IPv6 over DECT ULE ULE,
   such as for Internet of Things applications.

   This document describes how IPv6 is transported over DECT ULE using
   6LoWPAN
   IPv6 over Low-Power Wireless Personal Area Network (6LoWPAN)
   techniques.

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 7841.

   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 June 18, 2017.
   http://www.rfc-editor.org/info/rfc8105.

Copyright Notice

   Copyright (c) 2016 2017 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.  Requirements Notation . . . . . . . . . . . . . . . . . .   4   3
     1.2.  Terms Used  . . . . . . . . . . . . . . . . . . . . . . .   4
   2.  DECT Ultra Low Energy . . . . . . . . . . . . . . . . . . . .   6   5
     2.1.  The DECT ULE Protocol Stack . . . . . . . . . . . . . . .   6   5
     2.2.  Link Layer Roles and Topology . . . . . . . . . . . . . .   7   6
     2.3.  Addressing Model  . . . . . . . . . . . . . . . . . . . .   8   7
     2.4.  MTU Considerations  . . . . . . . . . . . . . . . . . . .   9   8
     2.5.  Additional Considerations . . . . . . . . . . . . . . . .   9   8
   3.  Specification of IPv6 over DECT ULE . . . . . . . . . . . . .   9   8
     3.1.  Protocol Stack  . . . . . . . . . . . . . . . . . . . . .  10   9
     3.2.  Link Model  . . . . . . . . . . . . . . . . . . . . . . .  10   9
     3.3.  Subnets and Internet Connectivity Scenarios . . . . . . .  15  14
   4.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  17  16
   5.  Security Considerations . . . . . . . . . . . . . . . . . . .  17  16
   6.  ETSI Considerations . . . . . . . . . . . . . . . . . . . . .  18  16
   7.  Acknowledgements  References  . . . . . . . . . . . . . . . . . . . . . . . .  18
   8.  References .  17
     7.1.  Normative References  . . . . . . . . . . . . . . . . . .  17
     7.2.  Informative References  . . . . . .  18
     8.1.  Normative References . . . . . . . . . . .  18
   Acknowledgements  . . . . . . .  18
     8.2.  Informative References . . . . . . . . . . . . . . . . .  20
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  21  20

1.  Introduction

   Digital Enhanced Cordless Telecommunications (DECT) is a standard
   series [EN300.175-part1-7] specified by ETSI ETSI, and CAT-iq (Cordless
   Advanced Technology - internet and quality) is a set of product
   certification and interoperability profiles [CAT-iq] defined by DECT
   Forum.  DECT Ultra Low Energy (DECT ULE or just ULE) is an air
   interface technology building on the key fundamentals of traditional
   DECT / CAT-iq
   DECT/CAT-iq but with specific changes to significantly reduce the
   power consumption at the expense of data throughput.  DECT ULE
   devices with requirements on power consumption consumption, as specified by ETSI
   in [TS102.939-1] and [TS102.939-2], will operate on special power power-
   optimized silicon, silicon but can connect to a DECT Gateway supporting
   traditional DECT / CAT-iq DECT/CAT-iq for cordless telephony and data as well as
   the ULE extensions.

   DECT terminology has two major role definitions: The the Portable Part
   (PP) is the power constrained device, power-constrained device while the Fixed Part (FP) is the
   Gateway or base station.  This FP may be connected to the Internet.
   An example of a use case for DECT ULE is a home security home-security sensor
   transmitting small amounts of data (few bytes) at periodic intervals
   through the FP, FP but that is able to wake up upon an external event (burglar)
   (e.g., a break-in) and communicate with the FP.  Another example
   incorporating both DECT ULE as well as and traditional CAT-iq telephony
   is would be
   a pendant (brooch) for the elderly which can transmit that generally transmits periodic
   status messages to a care provider using very little battery, but in
   the event of urgency, an emergency, the elderly person can establish a voice
   connection through the pendant to an alarm service.  It is expected
   that DECT ULE will be integrated into many residential gateways, as
   many of these already implement DECT CAT-iq for cordless telephony.
   DECT ULE can be added as a software option for the FP.

   It is desirable to consider IPv6 for DECT ULE devices due to the
   large address space and well-known infrastructure.  This document
   describes how IPv6 is used on DECT ULE links to optimize power while
   maintaining the many benefits of IPv6 transmission.  [RFC4944],
   [RFC6282]
   [RFC6282], and [RFC6775] specify the transmission of IPv6 over IEEE
   802.15.4.  DECT ULE has many characteristics similar to those of IEEE
   802.15.4, but it also has differences.  A subset of mechanisms
   defined for transmission of IPv6 over IEEE 802.15.4 can be applied to
   the transmission of IPv6 on DECT ULE links.

   This document specifies how to map IPv6 over DECT ULE inspired by
   [RFC4944], [RFC6282], [RFC6775] [RFC6775], and [RFC7668].

1.1.  Requirements Notation

   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].

1.2.  Terms Used

   6CO      6LoWPAN Context Option [RFC6775]
   6BBR     6loWPAN Backbone Router
   6LBR     6LoWPAN Border Router Router, as defined in [RFC6775].
            The DECT Fixed Part is having has this role role.
   6LN      6LoWPAN Node as defined in [RFC6775].
            The DECT Portable part
           is having Part has this role
   6LoWPAN  IPv6 over Low-Power Wireless Personal Area Network
   AES128   Advanced Encryption Standard with a key size of 128 bits
   API      Application Programming Interface
   ARO      Address Registration Option [RFC6775]
   CAT-iq   Cordless Advanced Technology - internet and quality
   CID      Context Identifier [RFC6775]
   DAC      Destination Address Compression
   DAD      Duplicate Address Detection [RFC4862]
   DAM      Destination Address Mode
   DHCPv6   Dynamic Host Configuration Protocol for IPv6 [RFC3315]
   DLC      Data Link Control
   DSAA2    DECT Standard Authentication Algorithm #2
   DSC      DECT Standard Cipher
   DSC2     DECT Standard Cipher #2
   FDMA     Frequency Division Multiplex     Frequency-Division Multiple Access
   FP       DECT Fixed Part, Part; the gateway Gateway
   GAP      Generic Access Profile
   IID      Interface Identifier
   IPEI     International Portable Equipment Identity; (DECT identity) DECT identity
   MAC-48   48 bit   48-bit global unique MAC address managed by IEEE
   MAC      Media Access Control
   MTU      Maximum Transmission Unit
   NBMA     Non-broadcast multi-access     Non-Broadcast Multi-Access
   ND       Neighbor Discovery [RFC4861] [RFC6775]
   PDU      Protocol Data Unit
   PHY      Physical Layer
   PMID     Portable MAC Identity; (DECT identity) DECT identity
   PP       DECT Portable Part, Part; typically the sensor node (6LN)
   PVC      Permanent Virtual Circuit
   RFPI     Radio Fixed Part Identity; (DECT identity) DECT identity
   SAC      Source Address Compression
   SAM      Source Address Mode
   TDD      Time Division Duplex
   TDMA     Time Division Multiplex     Time-Division Multiple Access
   TPUI     Temporary Portable User Identity; (DECT identity) DECT identity
   UAK      User Authentication Key, Key; DECT master security key
   ULA      Unique Local Address [RFC4193]

2.  DECT Ultra Low Energy

   DECT ULE is a low power low-power air interface technology that is designed to
   support both circuit switched circuit-switched services, such as voice communication,
   and packet mode packet-mode data services at a modest data rate.  This draft document
   is only addressing the packet mode packet-mode data service of DECT ULE.

2.1.  The DECT ULE Protocol Stack

   The DECT ULE protocol stack Protocol Stack contains a PHY layer operating at
   frequencies in the 1880 - 1920 MHz frequency band depending on the
   region and uses a symbol rate of 1.152 Mbaud.  Radio bearers are
   allocated by use of FDMA/TDMA/TDD techniques.

   In its generic network topology, DECT is defined as a cellular
   network technology.  However, the most common configuration is a star
   network with a single FP defining the network with a number of PP PPs
   attached.  The MAC layer supports both traditional DECT circuit mode
   operation
   operation, as this is used for services like discovery, pairing,
   security features etc, features, etc., and it supports new ULE packet mode packet-mode
   operation.  The circuit mode circuit-mode features have been reused from DECT.

   The DECT ULE device can switch to the ULE mode of operation,
   utilizing the new ULE MAC layer features.  The DECT ULE Data Link
   Control (DLC) provides multiplexing as well as segmentation and re-
   assembly
   reassembly for larger packets from layers above.  The DECT ULE layer
   also implements per-message authentication and encryption.  The DLC
   layer ensures packet integrity and preserves packet order, but
   delivery is based on best effort.

   The current DECT ULE MAC layer standard supports low bandwidth low-bandwidth data
   broadcast.  However, this document is not considering usage of the
   DECT ULE MAC layer broadcast service for IPv6 over DECT ULE.

   In general, communication sessions can be initiated from both the FP
   side and the PP side.  Depending on power down power-down modes employed in the
   PP, latency may occur when initiating sessions from the FP side.  MAC
   layer communication can take place using either connection oriented connection-oriented
   packet transfer with low overhead for short sessions or take place using
   connection connection-
   oriented bearers including media reservation.  The MAC layer
   autonomously selects the radio spectrum radio-spectrum positions that are available
   within the band and can rearrange these to avoid interference.  The
   MAC layer has built-in retransmission procedures in order to improve
   transmission reliability.

   The DECT ULE device will typically incorporate an application
   programming interface (API) Application
   Programming Interface (API), as well as common elements known as
   Generic Access Profile (GAP) Profiles (GAPs), for enrolling into the network.  The
   DECT ULE stack Stack establishes a permanent virtual circuit Permanent Virtual Circuit (PVC) for the
   application layers and provides support for a range of different
   application protocols.  The application protocol is negotiated
   between the PP and FP when the PVC communication service is
   established.  [TS102.939-1] defines this negotiation and specifies an
   Application Protocol Identifier of set to 0x06 for 6LowPAN. 6LoWPAN.  This
   document defines the behavior of that Application Protocol. application protocol.

              +----------------------------------------+
              |          Application Layers            |
              +----------------------------------------+
              | Generic Access     |     ULE Profile   |
              |       Profile      |                   |
              +----------------------------------------+
              | DECT/Service API   | ULE Data API      |
              +--------------------+-------------------+
              | LLME  | NWK (MM,CC)|                   |
              +--------------------+-------------------+
              | DECT DLC           | DECT ULE DLC      |
              +--------------------+-------------------+
              |                MAC Layer               |
              +--------------------+-------------------+
              |                PHY Layer               |
              +--------------------+-------------------+
                    (C-plane)             (U-plane)

                     Figure 1: DECT ULE Protocol Stack

   Figure 1 above shows the DECT ULE Stack divided into the Control-
   plane Control Plane
   (C-plane) and User-data plane, User Data Plane (U-plane), to the left and to the
   right, respectively.  The shown entities in the Stack are the (PHY)
   Physical Layer, (MAC) Layer (PHY), Media Access Control (MAC) Layer, (DLC) Data Link
   Control (DLC) Layer, (NWK) and Network Layer (NWK), along with following
   subcomponents: (LLME) Lower Layer Lower-Layer Management
   Entity, (MM) Entity (LLME), Mobility
   Management (MM), and (CC) Call Control. Control (CC).  Above there are the typically (API) typical
   Application Programmers Interface (API) and
   application profile application-profile-
   specific layers.

2.2.  Link Layer Roles and Topology

   A

   An FP is assumed to be less constrained than a PP.  Hence, in the
   primary scenario scenario, the FP and PP will act as 6LBR and a 6LN,
   respectively.  This document only addresses this primary scenario scenario,
   and all other scenarios with different roles of an FP and PP are out
   of scope.

   In DECT ULE, at the link layer layer, the communication only takes place
   between
   a an FP and a PP.  A  An FP is able to handle multiple
   simultaneous connections with a number of PP. PPs.  Hence, in a DECT ULE
   network using IPv6, a radio hop is equivalent to an IPv6 link and
   vice versa (see Section 3.3).

       [DECT ULE PP]-----\                 /-----[DECT ULE PP]
                          \               /
       [DECT ULE PP]-------+[DECT ULE FP]+-------[DECT ULE PP]
                          /               \
       [DECT ULE PP]-----/                 \-----[DECT ULE PP]

                     Figure 2: DECT ULE star topology Star Topology

   A significant difference between IEEE 802.15.4 and DECT ULE is that
   the former supports both star and mesh topology (and requires a
   routing protocol), whereas DECT ULE in its primary configuration does
   not support the formation of multihop networks at the link layer.  In
   consequence, the mesh header defined in [RFC4944] is not used in DECT
   ULE networks.

   DECT ULE repeaters are considered to operate transparently in the
   DECT protocol domain and are outside the scope of this document.

2.3.  Addressing Model

   Each DECT PP is assigned an IPEI during manufacturing.  This identity
   has the size of 40 bits and is globally unique within DECT addressing
   space and can be used to constitute the MAC address used to derive
   the IID for link-local address.

   During a DECT location registration procedure, the FP assigns a 20
   bit
   20-bit TPUI to a PP.  The FP creates a unique mapping between the
   assigned TPUI and the IPEI of each PP.  This TPUI is used for
   addressing (layer (Layer 2) in messages between the FP and PP.  Although the
   TPUI is temporary by definition, many implementations assign the same
   value repeatedly to any given PP, hence it seems not suitable for
   construction of IID, see [I-D.ietf-6lo-privacy-considerations]. the IID (see [RFC8065]).

   Each DECT FP is assigned a an RFPI during manufacturing.  This identity
   has the size of 40 bits and is globally unique within DECT addressing
   space and can be used to constitute the MAC address used to derive
   the IID for link-local address.

   Optionally

   Optionally, each DECT PP and DECT FP can be assigned a unique (IEEE)
   MAC-48 address additionally in addition to the DECT identities to be used by the
   6LoWPAN.  During the address registration of non-link-local addresses
   as specified by this document, the FP and PP can use such MAC-48 to
   construct the IID.  However, as these addresses are considered as
   being permanent, such a scheme is NOT RECOMMENDED as per [I-D.ietf-6lo-
   privacy-considerations]. [RFC8065].

2.4.  MTU Considerations

   Ideally

   Ideally, the DECT ULE FP and PP may generate data that fits into a
   single MAC Layer packets layer packet (38 octets) for periodically transferred
   information, depending on application.  However, IP packets may be
   much larger.  The DECT ULE DLC procedures natively support
   segmentation and reassembly and provide any MTU size below 65536
   octets.  The default MTU size defined in DECT ULE [TS102.939-1] is
   500 octets.  In order to support complete IPv6 packets, the DLC layer
   of DECT ULE SHALL SHALL, per this specification specification, be configured with a an MTU
   size of 1280 octets, hence [RFC4944] fragmentation/reassembly is not
   required.

   It is important to realize that the usage of larger packets will be
   at the expense of battery life, as a large packet inside the DECT ULE
   stack
   Stack will be fragmented into several or many MAC layer packets, each
   consuming power to transmit / receive. transmit/receive.  The increased MTU size does not
   change the MAC layer packet and PDU size.

2.5.  Additional Considerations

   The DECT ULE standard allows the PP to be DECT-registered (bound) to
   multiple FP and to roam between them.  These FP and their 6LBR
   functionalities can either operate either individually or connected through
   a Backbone Router as per [I-D.ietf-6lo-backbone-router]. [BACKBONE-ROUTER].

3.  Specification of IPv6 over DECT ULE

   Before any IP-layer communications can take place over DECT ULE, DECT
   ULE enabled
   DECT-ULE-enabled nodes such as 6LNs and 6LBRs have to find each other
   and establish a suitable link-layer link layer connection.  The obtain-access-rights obtain-access-
   rights registration and location registration procedures are
   documented by ETSI in the specifications [EN300.175-part1-7], [TS102.939-1]
   [TS102.939-1], and [TS102.939-2].

   DECT ULE technology sets strict requirements for low power
   consumption and thus and, thus, limits the allowed protocol overhead. 6LoWPAN
   standards [RFC4944], [RFC6775], and [RFC6282] provide useful
   functionality for reducing overhead which that can be applied to DECT ULE.
   This functionality comprises link-local IPv6 addresses and stateless
   IPv6 address autoconfiguration, Neighbor Discovery Discovery, and header
   compression.

   The ULE 6LoWPAN adaptation layer can run directly on this U-plane DLC
   layer.  Figure 3 illustrates an IPv6 over DECT ULE stack. Stack.

   Because DECT ULE in its primary configuration does not support the
   formation of multihop networks at the link layer, the mesh header
   defined in [RFC4944] for mesh under routing MUST NOT be used.  In
   addition, the role of a 6LoWPAN Router (6LR) is not defined per this
   specification.

3.1.  Protocol Stack

   In order to enable data transmission over DECT ULE, a Permanent
   Virtual Circuit (PVC) has to be configured and opened between the FP
   and PP.  This is done by setting up a DECT service call between the
   PP and FP.  In the DECT protocol domain domain, the PP SHALL specify the <<IWU-
   ATTRIBUTES>>
   <<IWU-ATTRIBUTES>> in a service-change (other) message before sending
   a service-change (resume) message as defined in [TS102.939-1].  The
   <<IWU-ATTRIBTES>>
   <<IWU-ATTRIBUTES>> SHALL define set the ULE Application Protocol Identifier
   to 0x06 and the MTU size to 1280 octets or larger.  The FP sends a
   service-change-accept (resume) that MUST contain a valid paging
   descriptor.  The PP MUST listen to paging messages from the FP
   according to the information in the received paging descriptor.
   Following this, transmission of IPv6 packets can start.

                     +-------------------+
                     |    UDP/TCP/other  |
                     +-------------------+
                     |       IPv6        |
                     +-------------------+
                     |6LoWPAN adapted to |
                     |    DECT ULE       |
                     +-------------------+
                     |  DECT ULE DLC     |
                     +-------------------+
                     |  DECT ULE MAC     |
                     +-------------------+
                     |  DECT ULE PHY     |
                     +-------------------+

                    Figure 3: IPv6 over DECT ULE Stack

3.2.  Link Model

   The general model is that IPv6 is layer Layer 3 and DECT ULE MAC+DLC is
   layer MAC and DECT
   ULE DLC are Layer 2.  The  DECT ULE already implements fragmentation and
   reassembly functionality, hence [RFC4944] functionality; hence, the fragmentation and reassembly
   function described in [RFC4944] MUST NOT be used.

   After the FP FPs and PPs have connected at the DECT ULE level, the link
   can be considered up and IPv6 address configuration and transmission
   can begin.  The 6LBR ensures address collisions do not occur.

   Per this specification, the IPv6 header compression format specified
   in [RFC6282] MUST be used.  The IPv6 payload length can be derived
   from the ULE DLC packet length and the length.  The possibly elided IPv6 address can
   be reconstructed from the link-layer address, used at the time of
   DECT ULE connection establishment, from the ULE MAC packet address,
   compression context if any, and from lower layer address registration information (see Section 3.2.2). 3.2.4).

   Due to the DECT ULE star topology (see Section 2.2), each PP has a
   separate link to the FP, and thus FP; thus, the PPs cannot directly hear one
   another and cannot talk to one another.  As discussed in [RFC4903],
   conventional usage of IPv6 anticipates IPv6 subnets spanning a single
   link at the link layer.  In order to avoid the complexity of
   implementing a separate subnet for each DECT ULE link, a Multi-Link
   Subnet model [RFC4903] has been chosen, specifically Non-broadcast
   multi-access Non-Broadcast
   Multi-Access (NBMA) at layer Layer 2.  Because of this, link-local
   multicast communications can happen only within a single DECT ULE
   connection; thus, 6LN-to-6LN communications using link-local
   addresses are not possible. 6LNs connected to the same 6LBR have to
   communicate with each other by using utilizing the shared prefix used on the
   subnet.  The 6LBR forwards packets sent by one 6LN to another.

3.2.1.  Stateless Address Autoconfiguration

   At network interface initialization, both 6LN and 6LBR SHALL generate
   and assign IPv6 link-local addresses to the DECT ULE network interface IPv6 link-local
   addresses
   interfaces [RFC4862] based on the DECT device addresses (see
   Section 2.3) that were used for establishing the underlying DECT ULE
   connection.

   The DECT device addresses IPEI and RFPI MUST be used to derive the
   IPv6 link-local 64 bit 64-bit Interface Identifiers (IID) (IIDs) for 6LN and 6LBR,
   respectively.

   The rule for deriving IID IIDs from DECT device addresses is as follows:
   The
   the DECT device addresses that are consisting consist of 40 bits each, each MUST be
   expanded with leading zero bits to form 48 bit 48-bit intermediate
   addresses.  Most  The most significant bit in this newly formed 48-bit
   intermediate address is set to one for addresses derived from the
   RFPI and set to zero for addresses derived from the IPEI.  From 64-bit IIDs
   are derived from these intermediate 48 bit 48-bit addresses are derived 64 bit IIDs following the
   guidance in Appendix A of [RFC4291].  However, because DECT and IEEE
   address spaces are different, this intermediate address cannot be
   considered as to be unique within an IEEE address space.  In the derived IIDs
   IIDs, the U/L Universal/Local (U/L) bit (7th bit) will be zero, indicating which
   indicates that derived IID's IIDs are not globally unique, see [RFC7136].
   For example example, from
   RFPI=11.22.33.44.55 RFPI=11.22.33.44.55, the derived IID is 80:11:22:ff:fe:33:44:55 and
   80:11:22:ff:fe:33:44:55; from IPEI=01.23.45.67.89 IPEI=01.23.45.67.89, the derived IID is
   00:01:23:ff:fe:45:67:89.

   Globally

   Global uniqueness of an IID in link-local addresses are is not required
   as they should never be leaked outside the subnet domain.

   As defined in [RFC4291], the IPv6 link-local address is formed by
   appending the IID, IID to the prefix FE80::/64, as shown in Figure 4.

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

               Figure 4: IPv6 link-local address Link-Local Address in DECT ULE

   A 6LN MUST join the all-nodes multicast address.

   After link-local address configuration, 6LN sends Router Solicitation
   messages as described in [RFC4861] Section 6.3.7 of [RFC4861] and [RFC6775] Section 5.3. 5.3
   of [RFC6775].

   For non-link-local addresses, 6LNs SHOULD NOT be configured to use
   IIDs derived from a MAC-48 device address or DECT device addresses.
   Alternative schemes such as Cryptographically Generated Addresses
   (CGAs) [RFC3972], privacy extensions [RFC4941], Hash-Based Addresses
   (HBAs) [RFC5535], DHCPv6 [RFC3315], or static, semantically opaque
   addresses [RFC7217] SHOULD be used by default.  See also [I-D.ietf-
   6lo-privacy-considerations] [RFC8065]
   for guidance of needed entropy in IIDs and the recommended lifetime
   of used IIDs.  When generated IID's IIDs are not globally unique, Duplicate
   Address Detection (DAD) [RFC4862] MUST be used.  In situations where
   deployment constraints require the device's address to be embedded in
   the IID, the 6LN MAY form a 64-bit IID by utilizing the MAC-48 device
   address or DECT device addresses.  The non-link-local addresses that
   a 6LN generates MUST be registered with 6LBR as described in
   Section 3.2.2.

   The means for a 6LBR to obtain an IPv6 prefix for numbering the DECT
   ULE network is out of scope of this document, but a prefix can be,
   for example, accomplished assigned via DHCPv6 Prefix Delegation [RFC3633] or by using Unique Local
   IPv6 Unicast Unique Local Addresses (ULA) (ULAs) [RFC4193].  Due to the
   link model of the DECT ULE ULE, the 6LBR MUST set the "on-link" flag (L) flag
   to zero in the Prefix Information Option [RFC4861].  This will cause
   6LNs to always send packets to the 6LBR, including the case when the
   destination is another 6LN using the same prefix.

3.2.2.  Neighbor Discovery

   'Neighbor

   "Neighbor Discovery Optimization for IPv6 over Low-Power Wireless
   Personal Area Networks (6LoWPANs)' (6LoWPANs)" [RFC6775] describes the neighbor
   discovery Neighbor
   Discovery approach as adapted for use in several 6LoWPAN topologies,
   including the mesh topology.  As DECT ULE does not support mesh
   networks, only those aspects of [RFC6775] that apply to star topology
   are considered.

   The following aspects of the Neighbor Discovery optimizations
   [RFC6775] are applicable to DECT ULE 6LNs:

   1.  For sending Router Solicitations and processing Router
       Advertisements the DECT ULE 6LNs MUST, respectively, follow
       Sections 5.3 and 5.4 of the [RFC6775].

   2.  A DECT ULE 6LN MUST NOT register its link-local address.  Because
       the IIDs used in link-local addresses are derived from DECT
       addresses, there will always exist a unique mapping between link-
       local and layer-2 Layer 2 addresses.

   3.  A DECT ULE 6LN MUST register its non-link-local addresses with
       the 6LBR by sending a Neighbor Solicitation (NS) message with the
       Address Registration Option (ARO) and process the Neighbor
       Advertisement (NA) accordingly.  The NS with the ARO option MUST
       be sent irrespective of the method used to generate the IID.

3.2.3.  Unicast and Multicast Address Mapping

   The DECT MAC layer broadcast service is considered inadequate for IP
   multicast,
   multicast because it does not support the MTU size required by IPv6.

   Hence

   Hence, traffic is always unicast between two DECT ULE nodes.  Even in
   the case where a 6LBR is attached to multiple 6LNs, the 6LBR cannot
   do a multicast to all the connected 6LNs.  If the 6LBR needs to send
   a multicast packet to all its 6LNs, it has to replicate the packet
   and unicast it on each link.  However, this may not be energy- energy
   efficient and particular care should be taken if the FP is battery-
   powered.  To further conserve power, the 6LBR MUST keep track of
   multicast listeners at DECT-ULE link level granularity DECT ULE link-level granularity, and it MUST
   NOT forward multicast packets to 6LNs that have not registered for
   multicast groups the packets belong to.  In the opposite direction, a
   6LN can only transmit data to or through the 6LBR.  Hence, when a 6LN
   needs to transmit an IPv6 multicast packet, the 6LN will unicast the
   corresponding DECT ULE packet to the 6LBR.  The 6LBR will then
   forward the multicast packet to other 6LNs.

3.2.4.  Header Compression

   Header compression as

   As defined in [RFC6282], which specifies the compression format for
   IPv6 datagrams on top of IEEE 802.15.4, header compression is
   REQUIRED in this document as the basis for IPv6 header compression on
   top of DECT ULE.  All headers MUST be compressed according to
   [RFC6282]
   encoding formats. formats as described in [RFC6282].  The DECT ULE's star
   topology structure, ARO and 6CO 6CO, can be exploited in order to provide
   a mechanism for address compression.  The following text describes
   the principles of IPv6 address compression on top of DECT ULE.

3.2.4.1.  Link-local  Link-Local Header Compression

   In a link-local communication terminated at 6LN and 6LBR, both the
   IPv6 source and destination addresses MUST be elided, elided since the used
   IIDs map uniquely into the DECT link end point end-point addresses.  A 6LN or
   6LBR that receives a PDU containing an IPv6 packet can infer the
   corresponding IPv6 source address.  For the unicast type of
   communication considered in this paragraph, the following settings
   MUST be used in the IPv6 compressed header: CID=0, SAC=0, SAM=11,
   DAC=0, and DAM=11.

3.2.4.2.  Non-link-local Header Compression

   To enable efficient header compression, the 6LBR MUST include the
   6LoWPAN Context Option (6CO) [RFC6775] for all prefixes the 6LBR
   advertises in Router Advertisements for use in stateless address
   autoconfiguration.

   When a 6LN transmits an IPv6 packet to a destination using global
   Unicast
   unicast IPv6 addresses, if a context is defined for the prefix of the
   6LNs global IPv6 address, the 6LN MUST indicate this context in the
   corresponding source fields of the compressed IPv6 header as per
   Section 3.1 of [RFC6282], [RFC6282] and MUST fully elide the latest registered
   IPv6 source address.  For this, the 6LN MUST use the following
   settings in the IPv6 compressed header: CID=1, SAC=1, and SAM=11.  In
   this case, the 6LBR can infer the elided IPv6 source address since 1)
   the 6LBR has previously assigned the prefix to the 6LNs; 6LNs and 2) the
   6LBR maintains a Neighbor Cache that relates the Device Address device address and
   the IID of the corresponding PP.  If a context is defined for the
   IPv6 destination address, the 6LN MUST also indicate this context in
   the corresponding destination fields of the compressed IPv6 header, header
   and MUST elide the prefix of the destination IPv6 address.  For this,
   the 6LN MUST set the DAM field of the compressed IPv6 header as
   CID=1, DAC=1 DAC=1, and DAM=01 or DAM=11.  Note that when a context is
   defined for the IPv6 destination address, the 6LBR can infer the
   elided destination prefix by using the context.

   When a 6LBR receives a an IPv6 packet having a global Unicast unicast IPv6
   address,
   address and the destination of the packet is a 6LN, if a context is
   defined for the prefix of the 6LN's global IPv6 address, the 6LBR
   MUST indicate this context in the corresponding destination fields of
   the compressed IPv6 header, header and MUST fully elide the IPv6 destination
   address of the packet if the destination address is the latest
   registered by the 6LN for the indicated context.  For this, the 6LBR
   MUST set the DAM field of the IPv6 compressed header as DAM=11.  CID
   and DAC MUST be set to CID=1 and DAC=1.  If a context is defined for
   the prefix of the IPv6 source address, the 6LBR MUST indicate this
   context in the source fields of the compressed IPv6 header, header and MUST
   elide that prefix as well.  For this, the 6LBR MUST set the SAM field
   of the IPv6 compressed header as CID=1, SAC=1 SAC=1, and SAM=01 or SAM=11.

3.3.  Subnets and Internet Connectivity Scenarios

   In the DECT ULE star topology (see Section 2.2), PP each have PP has a
   separate link to the FP FP, and the FP acts as an IPv6 router rather
   than a link-layer link layer switch.  A Multi-Link Subnet model [RFC4903] has
   been chosen, specifically Non-broadcast multi-access Non-Broadcast Multi-Access (NBMA) at layer 2 Layer
   2, as is further illustrated in Figure 5.  The 6LBR forwards packets
   sent by one 6LN to another.  In a typical scenario, the DECT ULE
   network is connected to the Internet as shown in the Figure 5.  In
   this scenario, the DECT ULE network is deployed as one subnet, subnet using
   one /64 IPv6 prefix.  The 6LBR is acting acts as a router and forwarding forwards packets
   between 6LNs and to and from Internet.

                          6LN
                           \               ____________
                            \             /            \
                    6LN ---- 6LBR ------ |  Internet    |
                            /             \____________/
                           /
                          6LN

                <--  One subnet -->
                <--   DECT ULE  -->

           Figure 5: DECT ULE network connected Network Connected to the Internet

   In some scenarios, the DECT ULE network may transiently or
   permanently be an isolated network as shown in the Figure 6.  In this
   case
   case, the whole DECT ULE network consists of a single subnet with
   multiple links, where 6LBR is routing packets between 6LNs.

                         6LN      6LN
                          \      /
                           \    /
                    6LN --- 6LBR --- 6LN
                           /    \
                          /      \
                         6LN      6LN

                    <----  One subnet ---->
                    <------ DECT ULE ----->

                    Figure 6: Isolated DECT ULE network Network

   In the isolated network scenario, communications between 6LN and 6LBR
   can use IPv6 link-local methodology, but for communications between
   different PP, the FP has to act as 6LBR, number the network with a
   ULA prefix [RFC4193], and route packets between the PP.

   In other more advanced systems scenarios with multiple FP FPs and 6LBR,
   each DECT ULE FP constitutes a wireless cell.  The network can be
   configured as a Multi-Link Subnet, Subnet in which the 6LN can operate within
   the same /64 subnet prefix in multiple cells as shown in the
   Figure 7.  The FPs in such a scenario should behave as Backbone
   Routers (6BBR) as defined in [I-D.ietf-6lo-backbone-router]. [BACKBONE-ROUTER].

                           ____________
                          /            \
                         |  Internet    |
                          \____________/
                                |
                                |
                                |
                                |
                    6BBR/       |        6BBR/
           6LN ---- 6LBR -------+------- 6LBR ---- 6LN
                   /  \                   /  \
                  /    \                 /    \
                 6LN   6LN              6LN   6LN

         <------------------One

     <------------------ One subnet ------------------>
     <-- DECT ULE Cell -->       <-- DECT ULE Cell -->

      Figure 7: Multiple DECT ULE cells Cells in a single Multi-Link subnet Single Multi-link Subnet

4.  IANA Considerations

   There are no

   This document does not require any IANA considerations related to this document. actions.

5.  Security Considerations

   The secure transmission of circuit mode services in DECT is based on
   the DSAA2 and DSC/DSC2 specifications developed by ETSI TC Technical
   Committee (TC) DECT and the ETSI SAGE Security expert group. Algorithms Group of Experts
   (SAGE).

   DECT ULE communications are secured at the link-layer link layer (DLC) by
   encryption and per-message authentication through CCM mode (Counter with CBC-MAC)
   Cipher Block Chaining Message Authentication Code (CBC-MAC)) mode
   similar to [RFC3610].  The underlying algorithm for providing
   encryption and authentication is AES128.

   The DECT ULE pairing procedure generates a master authentication key User Authentication
   Key (UAK).  During the location registration procedure procedure, or when the
   permanent virtual circuit circuits are established, the session security keys
   are generated.  Both the master authentication key and session
   security keys are generated by use of the DSAA2 algorithm
   [EN300.175-part1-7], which is using uses AES128 as the underlying algorithm.
   Session security keys may be renewed regularly.  The generated
   security keys (UAK and session security keys) are individual for each
   FP-PP binding, hence binding; hence, all PP PPs in a system have different security
   keys.  DECT ULE PPs do not use any shared encryption key.

   Even though DECT ULE offers link-layer link layer security, it is still
   recommended to use secure transport or application protocols above
   6LoWPAN.

   From the privacy point of view, the IPv6 link-local address
   configuration described in Section 3.2.1 only reveals information
   about the 6LN to the 6LBR that the 6LBR already knows from the link-layer link
   layer connection.  For non-link-local IPv6 addresses, by default default, a
   6LN SHOULD use a randomly generated IID, for example, as discussed in [I-D.ietf-6man-
   default-iids],
   [STABLE-IPv6], or use alternative schemes such as Cryptographically
   Generated Addresses (CGA) (CGAs) [RFC3972], privacy extensions [RFC4941],
   Hash-Based Addresses (HBA, (HBAs, [RFC5535]), or static, semantically
   opaque addresses [RFC7217].

6.  ETSI Considerations

   ETSI is standardizing a list of known application layer application-layer protocols
   that can use the DECT ULE permanent virtual circuit packet data
   service.  Each protocol is identified by a unique known identifier,
   which is exchanged in the service-change procedure as defined in
   [TS102.939-1].  The IPv6/6LoWPAN as described in this document is
   considered as to be an application layer application-layer protocol on top of DECT ULE.
   In order to provide interoperability between 6LoWPAN / DECT ULE devices
   devices, a common protocol identifier for 6LoWPAN is standardized by
   ETSI.

   The ETSI DECT ULE Application Protocol Identifier is specified set to 0x06 for
   6LoWPAN [TS102.939-1].

7.  Acknowledgements

   We are grateful to the members of the IETF 6lo working group; this
   document borrows liberally from their work.

   Ralph Droms, Samita Chakrabarti, Kerry Lynn, Suresh Krishnan, Pascal
   Thubert, Tatuya Jinmei, Dale Worley and Robert Sparks have provided
   valuable feedback for this draft.

8.  References

8.1.

7.1.  Normative References

   [EN300.175-part1-7]
              ETSI, "Digital Enhanced Cordless Telecommunications
              (DECT); Common Interface (CI);", March (CI); Part 1: Overview", European
              Standard, ETSI EN 300 175-1, V2.6.1, July 2015,
              <https://www.etsi.org/deliver/
              etsi_en/300100_300199/30017501/02.06.01_60/
              en_30017501v020601p.pdf>.

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

   [RFC3633]  Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic
              Host Configuration Protocol (DHCP) version 6", RFC 3633,
              DOI 10.17487/RFC3633, December 2003,
              <http://www.rfc-editor.org/info/rfc3633>.

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

   [RFC4291]  Hinden, R. and S. Deering, "IP Version 6 Addressing
              Architecture", RFC 4291, DOI 10.17487/RFC4291, February
              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,
              DOI 10.17487/RFC4861, September 2007,
              <http://www.rfc-editor.org/info/rfc4861>.

   [RFC4862]  Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless
              Address Autoconfiguration", RFC 4862,
              DOI 10.17487/RFC4862, September 2007,
              <http://www.rfc-editor.org/info/rfc4862>.

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

   [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,
              <http://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,
              <http://www.rfc-editor.org/info/rfc6282>.

   [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,
              <http://www.rfc-editor.org/info/rfc6775>.

   [RFC7136]  Carpenter, B. and S. Jiang, "Significance of IPv6
              Interface Identifiers", RFC 7136, DOI 10.17487/RFC7136,
              February 2014, <http://www.rfc-editor.org/info/rfc7136>.

   [TS102.939-1]
              ETSI, "Digital Enhanced Cordless Telecommunications
              (DECT); Ultra Low Energy (ULE); Machine to Machine
              Communications; Part 1: Home Automation Network (phase
              1)", Technical Specification, ETSI TS 102 939-1, V1.2.1,
              March 2015, <https://www.etsi.org/deliver/
              etsi_ts/102900_102999/10293901/01.02.01_60/
              ts_10293901v010201p.pdf>.

   [TS102.939-2]
              ETSI, "Digital Enhanced Cordless Telecommunications
              (DECT); Ultra Low Energy (ULE); Machine to Machine
              Communications; Part 2: Home Automation Network (phase
              2)", Technical Specification, ETSI TS 102 939-2, V1.1.1,
              March 2015, <https://www.etsi.org/deliver/
              etsi_ts/102900_102999/10293902/01.01.01_60/
              ts_10293902v010101p.pdf>.

8.2.

7.2.  Informative References

   [BACKBONE-ROUTER]
              Thubert, P., "IPv6 Backbone Router", Work in Progress,
              draft-ietf-6lo-backbone-router-03, January 2017.

   [CAT-iq]   DECT Forum, "Cordless Advanced Technology - internet and
              quality", "CAT-iq at a Glance", January 2016,
              <http://www.dect.org/userfiles/Public/
              DF_CAT-iq%20at%20a%20Glance.pdf>.

   [I-D.ietf-6lo-backbone-router]
              Thubert, P., "IPv6 Backbone Router", draft-ietf-6lo-
              backbone-router-02 (work in progress), September 2016.

   [I-D.ietf-6lo-privacy-considerations]
              Thaler, D., "Privacy Considerations for IPv6 Adaptation
              Layer Mechanisms", draft-ietf-6lo-privacy-
              considerations-04 (work in progress), October 2016.

   [I-D.ietf-6man-default-iids]
              Gont, F., Cooper, A., Thaler, D., and S. LIU,
              "Recommendation on Stable IPv6 Interface Identifiers",
              draft-ietf-6man-default-iids-16 (work in progress),
              September 2016.

   [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, <http://www.rfc-editor.org/info/rfc3315>.

   [RFC3610]  Whiting, D., Housley, R., and N. Ferguson, "Counter with
              CBC-MAC (CCM)", RFC 3610, DOI 10.17487/RFC3610, September
              2003, <http://www.rfc-editor.org/info/rfc3610>.

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

   [RFC4903]  Thaler, D., "Multi-Link Subnet Issues", RFC 4903,
              DOI 10.17487/RFC4903, June 2007,
              <http://www.rfc-editor.org/info/rfc4903>.

   [RFC5535]  Bagnulo, M., "Hash-Based Addresses (HBA)", RFC 5535,
              DOI 10.17487/RFC5535, June 2009,
              <http://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,
              <http://www.rfc-editor.org/info/rfc7217>.

   [RFC7668]  Nieminen, J., Savolainen, T., Isomaki, M., Patil, B.,
              Shelby, Z., and C. Gomez, "IPv6 over BLUETOOTH(R) Low
              Energy", RFC 7668, DOI 10.17487/RFC7668, October 2015,
              <http://www.rfc-editor.org/info/rfc7668>.

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

   [STABLE-IPv6]
              Gont, F., Cooper, A., Thaler, D., and S. LIU,
              "Recommendation on Stable IPv6 Interface Identifiers",
              Work in Progress, draft-ietf-6man-default-iids-16,
              September 2016.

Acknowledgements

   We are grateful to the members of the IETF 6lo working group; this
   document borrows liberally from their work.

   Ralph Droms, Samita Chakrabarti, Kerry Lynn, Suresh Krishnan, Pascal
   Thubert, Tatuya Jinmei, Dale Worley, and Robert Sparks have provided
   valuable feedback for this document.

Authors' Addresses

   Peter B. Mariager
   RTX A/S
   Stroemmen 6
   DK-9400 Noerresundby
   Denmark

   Email: pm@rtx.dk

   Jens Toftgaard Petersen (editor)
   RTX A/S
   Stroemmen 6
   DK-9400 Noerresundby
   Denmark

   Email: jtp@rtx.dk

   Zach Shelby
   ARM
   150 Rose Orchard
   San Jose, CA 95134
   USA
   United States of America

   Email: zach.shelby@arm.com

   Marco van de Logt
   Gigaset Communications
   Bosch Sensortec GmbH
   Frankenstrasse 2
   D-46395 Bocholt
   Gerhard-Kindler-Str. 9
   72770 Reutlingen
   Germany

   Email: marco.van-de-logt@gigaset.com marco.vandelogt@bosch-sensortec.com
   Dominique Barthel
   Orange Labs
   28 chemin du Vieux Chene
   38243 Meylan
   France

   Email: dominique.barthel@orange.com