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

Versions: (draft-mariager-6lowpan-v6over-dect-ule) 00 01 02 03 04 05 06 07 08 09 RFC 8105

6Lo Working Group                                            P. Mariager
Internet-Draft                                          J. Petersen, Ed.
Intended status: Standards Track                                 RTX A/S
Expires: November 17, 2016                                     Z. Shelby
                                                                     ARM
                                                          M. Van de Logt
                                             Gigaset Communications GmbH
                                                              D. Barthel
                                                             Orange Labs
                                                            May 16, 2016


        Transmission of IPv6 Packets over DECT Ultra Low Energy
                       draft-ietf-6lo-dect-ule-05

Abstract

   DECT Ultra Low Energy is a low power air interface technology that is
   defined by the DECT Forum and specified by ETSI.

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

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

   This document describes how IPv6 is transported over DECT ULE using
   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 of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.





Mariager, et al.        Expires November 17, 2016               [Page 1]


Internet-Draft             IPv6 over DECT ULE                   May 2016


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

   This Internet-Draft will expire on November 17, 2016.

Copyright Notice

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






Mariager, et al.        Expires November 17, 2016               [Page 2]


Internet-Draft             IPv6 over DECT ULE                   May 2016


1.  Introduction

   DECT Ultra Low Energy (DECT ULE or just ULE) is an air interface
   technology building on the key fundamentals of traditional DECT /
   CAT-iq but with specific changes to significantly reduce the power
   consumption at the expense of data throughput.  DECT (Digital
   Enhanced Cordless Telecommunications) is a standard series
   [EN300.175-part1-7] specified by ETSI and CAT-iq (Cordless Advanced
   Technology - internet and quality) is a set of product certication
   and interoperability profiles [CAT-iq] defined by DECT Forum.  DECT
   ULE devices with requirements on power consumption as specified by
   ETSI in [TS102.939-1] and [TS102.939-2], will operate on special
   power optimized silicon, but can connect to a DECT Gateway supporting
   traditional DECT / CAT-iq for cordless telephony and data as well as
   the ULE extensions.  DECT terminology operates with two major role
   definitions: The Portable Part (PP) is the 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 sensor transmitting small amounts of data (few
   bytes) at periodic intervals through the FP, but is able to wake up
   upon an external event (burglar) and communicate with the FP.
   Another example incorporating both DECT ULE as well as traditional
   CAT-iq telephony is an elderly pendant (broche) which can transmit
   periodic status messages to a care provider using very little
   battery, but in the event of urgency, 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 implements 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] 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 also 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] and [RFC7668].

1.1.  Requirements Notation

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




Mariager, et al.        Expires November 17, 2016               [Page 3]


Internet-Draft             IPv6 over DECT ULE                   May 2016


1.2.  Terms Used

   6CO:     6LoWPAN Context Option [RFC6775]
   6LBR:    DECT Fixed Part having a role as defined in [RFC6775]
   6LN:     DECT Portable part having a role as defined in [RFC6775]
   6LoWPAN: IPv6 over Low-Power Wireless Personal Area Network
   AES128:  Advanced Encryption Standard with 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
   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
   FP:      DECT Fixed Part, the gateway
   GAP:     Generic Access Profile
   IID:     Interface Identifier
   IPEI:    International Portable Equipment Identity; (DECT identity)
   MAC-48:  48 bit global unique MAC address managed by IEEE
   MAC:     Media Access Control
   MTU:     Maximum Transmission Unit
   ND:      Neighbor Discovery [RFC4861] [RFC6775]
   PDU:     Protocol Data Unit
   PHY:     Physical Layer
   PMID:    Portable MAC Identity; (DECT identity)
   PP:      DECT Portable Part, typically the sensor node (6LN)
   PVC:     Permanent Virtual Circuit
   RFPI:    Radio Fixed Part Identity; (DECT identity)
   SAC:     Source Address Compression
   SAM:     Source Address Mode
   TDD:     Time Division Duplex
   TDMA:    Time Division Multiplex
   TPUI:    Temporary Portable User Identity; (DECT identity)
   UAK:     User Authentication Key, DECT master security key
   ULA:     Unique Local Address [RFC4193]

2.  DECT Ultra Low Energy

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



Mariager, et al.        Expires November 17, 2016               [Page 4]


Internet-Draft             IPv6 over DECT ULE                   May 2016


2.1.  The DECT ULE Protocol Stack

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

   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
   attached.  The MAC layer supports both traditional DECT as this is
   used for services like discovery, pairing, security features etc.
   All these 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 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 data
   broadcast.  However, this document is not considering usage of the
   DECT ULE MAC layer broadcast service.

   In general, communication sessions can be initiated from both FP and
   PP side.  Depending on power down modes employed in the PP, latency
   may occur when initiating sessions from FP side.  MAC layer
   communication can take place using either connection oriented packet
   transfer with low overhead for short sessions or take place using
   connection oriented bearers including media reservation.  The MAC
   layer autonomously selects the 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
   Programmers Interface (API) as well as common elements known as
   Generic Access Profile (GAP) for enrolling into the network.  The
   DECT ULE stack establishes a permanent virtual circuit (PVC) for the
   application layers and provides support for a range of different
   application protocols.  The used application protocol is negotiated
   between the PP and FP when the PVC communication service is
   established.  This draft defines 6LoWPAN as one of the possible
   protocols to negotiate.





Mariager, et al.        Expires November 17, 2016               [Page 5]


Internet-Draft             IPv6 over DECT ULE                   May 2016


       +----------------------------------------+
       |          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 and User-data path, to left and to the right, respectively.
   The shown entities in the Stack are the (PHY) Physical Layer, (MAC)
   Media Access Control Layer, (DLC) Data Link Control Layer, (NWK)
   Network Layer with subcomponents: (LLME) Lower Layer Management
   Entity, (MM) Mobility Management and (CC) Call Control.  Above there
   are the typically (API) Application Programmers Interface and
   application profile specific layers.

2.2.  Link Layer Roles and Topology

   A FP is assumed to be less constrained than a PP.  Hence, in the
   primary scenario FP and PP will act as 6LBR and a 6LN, respectively.
   This document does only address this primary scenario.

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












Mariager, et al.        Expires November 17, 2016               [Page 6]


Internet-Draft             IPv6 over DECT ULE                   May 2016


       [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



   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 it's primary configuration
   does not support the formation of multihop networks at the link
   layer.  In consequence, the mesh header defined in [RFC4944] for mesh
   under routing are not used in DECT ULE networks.

   DECT ULE repeaters are not considered in 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 DECT globally unique for the PP and
   can be used to constitute the MAC address.  However, it cannot be
   used to derive a globally unique IID.

   When bound to a FP, a PP is assigned a 20 bit TPUI which is unique
   within the FP.  This TPUI is used for addressing (layer 2) in
   messages between FP and PP.

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

   Optionally each DECT PP and DECT FP can be assigned a unique (IEEE)
   MAC-48 address additionally 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.

2.4.  MTU Considerations

   Ideally the DECT ULE FP and PP may generate data that fits into a
   single MAC Layer packets (38 octets) for periodically transferred
   information, depending on application.  However, IP packets may be



Mariager, et al.        Expires November 17, 2016               [Page 7]


Internet-Draft             IPv6 over DECT ULE                   May 2016


   much larger.  The DECT ULE DLC procedures supports segmentation and
   reassembly of any MTU size below 65536 octets, but the default MTU
   size defined in DECT ULE [TS102.939-1] is 500 octets.  In order to
   support complete IP packets, the DLC layer of DECT ULE SHALL per this
   specification be configured with a MTU size that fits the
   requirements from IPv6 data packets, hence [RFC4944] fragmentation/
   reassembly is not required.

   It is expected that the LOWPAN_IPHC packet will fulfil all the
   requirements for header compression without spending unnecessary
   overhead for mesh addressing.

   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 will be fragmented into several or many MAC layer packets, each
   consuming power to transmit / receive.

2.5.  Additional Considerations

   The DECT ULE standard allows PP to be registered (bind) to multiple
   FP and roaming between these FP.  This draft does not consider the
   scenarios of PP roaming between multiple FP.  The use of repeater
   functionality is also not considered in this draft.

3.  Specification of IPv6 over DECT ULE

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

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

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

   As consequence of DECT ULE in it's 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




Mariager, et al.        Expires November 17, 2016               [Page 8]


Internet-Draft             IPv6 over DECT ULE                   May 2016


   used.  In addition, a DECT ULE PP node MUST NOT play the role of a
   6LoWPAN Router (6LR).

3.1.  Protocol Stack

   In order to enable transmission of IPv6 packets over DECT ULE, a
   Permanent Virtual Circuit (PVC) has to be opened between FP and PP.
   This MUST be done by setting up a service call from PP to FP.  The PP
   SHALL specify the <<IWU-ATTRIBUTES>> in a service-change (other)
   message before sending a service-change (resume) message as defined
   in [TS102.939-1].  The <<IWU-ATTRIBTES>> SHALL define the ULE
   Application Protocol Identifier to 0x06 and the MTU size to 1280
   octets or larger.  The FP MUST send a service-change-accept (resume)
   containing a valid paging descriptor.  The PP MUST be pageable.

                     +-------------------+
                     |    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 3 and DECT ULE MAC+DLC is
   layer 2.  The DECT ULE implements already fragmentation and
   reassembly functionality, hence [RFC4944] fragmentation and
   reassembly function MUST NOT be used.  The DECT ULE DLC link (PVC)
   MUST be configured with a minimum MTU size of at least 1280 octets in
   order to meet the size requirements of IPv6.

   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 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,



Mariager, et al.        Expires November 17, 2016               [Page 9]


Internet-Draft             IPv6 over DECT ULE                   May 2016


   compression context if any, and from address registration information
   (see Section 3.2.2).

   Due to DECT ULE star topology, each branch of the star is considered
   to be an individual link and thus the PPs cannot directly hear one
   another and cannot talk to one another with link-local addresses.
   However, the FP acts as a 6LBR for communication between the PPs.
   After the FP and PPs have connected at the DECT ULE level, the link
   can be considered up and IPv6 address configuration and transmission
   can begin.  The FP ensures address collisions do not occur.

3.2.1.  Stateless Address Autoconfiguration

   At network interface initialization, both 6LN and 6LBR SHALL generate
   and assign to the DECT ULE network interface IPv6 link-local
   addresses [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 Interface Identifiers (IID) for 6LN and 6LBR,
   respectively.

   The rule for deriving IID from DECT device addresses is as follows:
   The DECT device addresses that are consisting of 40 bits each, MUST
   be expanded with leading zero bits to form 48 bit intermediate
   addresses.  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 these
   intermediate 48 bit addresses are derived 64 bit IIDs according to
   the guidance of [RFC4291].  In the derived IIDs the U/L bit (7th bit)
   will be zero, indicating that derived IID's are not globally unique,
   see [RFC7136].  For example from RFPI=11.22.33.44.55 the derived IID
   is 80:11:22:ff:fe:33:44:55 and from IPEI=01.23.45.67.89 the derived
   IID is 00:01:23:ff:fe:45:67:89.

   As defined in [RFC4291], the IPv6 link-local address is formed by
   appending the 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 in DECT ULE





Mariager, et al.        Expires November 17, 2016              [Page 10]


Internet-Draft             IPv6 over DECT ULE                   May 2016


   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.

   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.  In situations where
   the devices address embedded in the IID are required to support
   deployment constraints, 6LN MAY form a 64-bit IID by utilizing the
   MAC-48 device address or DECT device addresses.  The non-link-local
   addresses 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 can be, for
   example, accomplished via DHCPv6 Prefix Delegation [RFC3633] or by
   using Unique Local IPv6 Unicast Addresses (ULA) [RFC4193].  Due to
   the link model of the DECT ULE the 6LBR MUST set the "on-link" flag
   (L) 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.

   A 6LN MUST NOT register more than one non-link-local address on the
   same prefix.

3.2.2.  Neighbor Discovery

   'Neighbor Discovery Optimization for IPv6 over Low-Power Wireless
   Personal Area Networks (6LoWPANs)' [RFC6775] describes the neighbor
   discovery approach as adapted for use in several 6LoWPAN topologies,
   including the mesh topology.  As DECT ULE is considered not to
   support mesh networks, hence only those aspects that apply to a 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.  A DECT
   ULE 6LN MUST register its non-link-local addresses with the 6LBR by
   sending a Neighbor Solicitation (NS) message with the Address



Mariager, et al.        Expires November 17, 2016              [Page 11]


Internet-Draft             IPv6 over DECT ULE                   May 2016


   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.  The 6LN MUST register only one
   IPv6 address per available IPv6 prefix.

3.2.3.  Unicast and Multicast Address Mapping

   The DECT MAC layer broadcast service is considered inadequate for IP
   multicast.

   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-
   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 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 defined in [RFC6282], which specifies the
   compression format for IPv6 datagrams on top of IEEE 802.15.4, 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.  The DECT ULE's star topology structure,
   ARO and 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 Header Compression

   In a link-local communication terminated at 6LN and 6LBR, both the
   IPv6 source and destination addresses MUST be elided, since the used
   IIDs map uniquely into the DECT link end point addresses.  A 6LN or
   6LBR that receives a PDU containing an IPv6 packet can infer the
   corresponding IPv6 source address.  For the 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, DAM=11.






Mariager, et al.        Expires November 17, 2016              [Page 12]


Internet-Draft             IPv6 over DECT ULE                   May 2016


3.2.4.2.  Non-link-local Header Compression

   To enable efficient header compression, the 6LBR MUST include 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 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], and MUST elide the IPv6 source address.
   For this, the 6LN MUST use the following settings in the IPv6
   compressed header: CID=1, SAC=1, 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; and 2) the 6LBR maintains a Neighbor
   Cache that relates the 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, 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 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 IPv6 packet having a global Unicast IPv6
   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, and MUST elide the IPv6 destination
   address of the packet before forwarding it to the 6LN.  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, 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 and SAM=01 or
   SAM=11.

3.3.  Subnets and Internet Connectivity Scenarios

   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, using one /64 IPv6 prefix.  The
   6LBR is acting as router and forwarding packets between 6LNs and to
   and from Internet.




Mariager, et al.        Expires November 17, 2016              [Page 13]


Internet-Draft             IPv6 over DECT ULE                   May 2016


   Other scenarios can be imagined where a PP is acting as 6LBR and
   providing Internet connectivity for the FP.  How the FP could then
   further provide Internet connectivity to other PP, possibly connected
   to the FP, is out of the scope of this document.


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

                    <-- DECT ULE -->


              Figure 5: DECT ULE 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 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

                    <------ DECT ULE ----->


                      Figure 6: Isolated DECT ULE 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 ULA
   prefix [RFC4193], and route packets between PP.







Mariager, et al.        Expires November 17, 2016              [Page 14]


Internet-Draft             IPv6 over DECT ULE                   May 2016


4.  IANA Considerations

   There are no IANA considerations related to this document.

5.  Security Considerations

   The secure transmission of speech over DECT will be based on the
   DSAA2 and DSC/DSC2 specification developed by ETSI TC DECT and the
   ETSI SAGE Security expert group.

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

   The DECT ULE pairing procedure generates a master authentication key
   (UAK).  During location registration procedure or when the permanent
   virtual circuit are established, the session security keys are
   generated.  Session security keys may be renewed regularly.  The
   generated security keys (UAK and session security keys) are
   individual for each FP-PP binding, hence all PP in a system have
   different security keys.  DECT ULE PPs do not use any shared
   encryption key.

   From 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 connection.
   For non-link-local IPv6 addresses, by default a 6LN SHOULD use a
   randomly generated IID, for example, as discussed in [I-D.ietf-6man-
   default- iids], or use alternative schemes such as Cryptographically
   Generated Addresses (CGA) [RFC3972], privacy extensions [RFC4941],
   Hash-Based Addresses (HBA, [RFC5535]), or static, semantically opaque
   addresses [RFC7217].

6.  ETSI Considerations

   ETSI is standardizing a list of known 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 an application layer protocol on top of DECT ULE.  In
   order to provide interoperability between 6LoWPAN / DECT ULE devices
   a common protocol identifier for 6LoWPAN is standardized by ETSI.

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




Mariager, et al.        Expires November 17, 2016              [Page 15]


Internet-Draft             IPv6 over DECT ULE                   May 2016


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 and Kerry Lynn have provided valuable
   feedback for this draft.

8.  References

8.1.  Normative References

   [EN300.175-part1-7]
              ETSI, "Digital Enhanced Cordless Telecommunications
              (DECT); Common Interface (CI);", March 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>.





Mariager, et al.        Expires November 17, 2016              [Page 16]


Internet-Draft             IPv6 over DECT ULE                   May 2016


   [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)", 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)", March 2015, <https://www.etsi.org/deliver/
              etsi_ts/102900_102999/10293902/01.01.01_60/
              ts_10293902v010101p.pdf>.

8.2.  Informative References

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




Mariager, et al.        Expires November 17, 2016              [Page 17]


Internet-Draft             IPv6 over DECT ULE                   May 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>.

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

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





Mariager, et al.        Expires November 17, 2016              [Page 18]


Internet-Draft             IPv6 over DECT ULE                   May 2016


   Zach Shelby
   ARM
   150 Rose Orchard
   San Jose, CA 95134
   USA

   Email: zach.shelby@arm.com


   Marco van de Logt
   Gigaset Communications GmbH
   Frankenstrasse 2
   D-46395 Bocholt
   Germany

   Email: marco.van-de-logt@gigaset.com


   Dominique Barthel
   Orange Labs
   28 chemin du Vieux Chene
   38243 Meylan
   France

   Email: dominique.barthel@orange.com


























Mariager, et al.        Expires November 17, 2016              [Page 19]


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