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

Versions: 00 01 02 03 draft-ietf-6lo-dect-ule

6LoWPAN                                                 P. Mariager, Ed.
Internet-Draft                                               J. Petersen
Intended status: Informational                                   RTX A/S
Expires: January 16, 2014                                      Z. Shelby
                                                               Sensinode
                                                           July 15, 2013


        Transmission of IPv6 Packets over DECT Ultra Low Energy
               draft-mariager-6lowpan-v6over-dect-ule-03

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 15 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/.

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




Mariager, et al.        Expires January 16, 2014                [Page 1]

Internet-Draft             IPv6 over DECT ULE                  July 2013


   This Internet-Draft will expire on January 16, 2014.

Copyright Notice

   Copyright (c) 2013 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  . . . . . . . . . . . . . . . . . . . . . . . .   2
     1.1.  Requirements Notation . . . . . . . . . . . . . . . . . .   3
     1.2.  Terms Used  . . . . . . . . . . . . . . . . . . . . . . .   3
   2.  DECT Ultra Low Energy . . . . . . . . . . . . . . . . . . . .   4
     2.1.  The DECT ULE Protocol Stack . . . . . . . . . . . . . . .   4
     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  . . . . . . . . . . . . . . . . . . . . .   8
     3.2.  Link model  . . . . . . . . . . . . . . . . . . . . . . .   8
     3.3.  Internet connectivity scenarios . . . . . . . . . . . . .  11
   4.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  12
   5.  Security Considerations . . . . . . . . . . . . . . . . . . .  13
   6.  ETSI Considerations . . . . . . . . . . . . . . . . . . . . .  13
   7.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .  13
   8.  Normative References  . . . . . . . . . . . . . . . . . . . .  13
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  14

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 on the expense of data throughput.  DECT ULE devices with
   requirements to power consumption 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



Mariager, et al.        Expires January 16, 2014                [Page 2]

Internet-Draft             IPv6 over DECT ULE                  July 2013


   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]
   specifies the transmission of IPv6 over IEEE 802.15.4.  DECT ULE has
   in many ways similar characteristics of IEEE 802.15.4, but also
   differences.  Many of the mechanisms defined in [RFC4944] 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

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

1.2.  Terms Used

   PP: DECT Portable Part, typically the sensor node

   FP: DECT Fixed Part, the gateway

   LLME: Lower Layer Management Entity

   NWK: Network









Mariager, et al.        Expires January 16, 2014                [Page 3]

Internet-Draft             IPv6 over DECT ULE                  July 2013


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.

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 then 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 the usage of this broadcast service has not yet
   been standardized for higher layers and no security has been
   developed been developed yet.  This document is not considering usage
   of this DECT ULE MAC broadcast service in current version.

   In general, communication sessions can be initiated from both FP and
   PP side.  Depending of power down modes employed in the PP, latency
   may occur when initiating sessions from FP side.  MAC layer
   communication can either take place using 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.





Mariager, et al.        Expires January 16, 2014                [Page 4]

Internet-Draft             IPv6 over DECT ULE                  July 2013


   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 proposes to define 6LoWPAN as one of the
   possible protocols to negotiate.

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

       Figure 1: DECT ULE Protocol Stack




   The DECT ULE stack can be divided into control (C-plane) and user-
   data (U-plane) parts shown to the left and to the right in figure 1,
   respectively.

   It is expected that the ULE 6LoWPAN adaptation layer can run directly
   on this U-plane DLC layer.  Figure 2 illustrates IPv6 over DECT ULE
   stack.

   Constrained Application Protocol (CoAP) is an application protocol
   specifically designed for resource constrained environments.  CoAP
   could be run on top of IPv6 supporting requests from the server and
   requests of cached replies from a CoAP/HTTP proxy in the DECT Fixed
   Part or in an external network infrastructure.





Mariager, et al.        Expires January 16, 2014                [Page 5]

Internet-Draft             IPv6 over DECT ULE                  July 2013


                     +-------------------+
                     |  Applications     |
                     +-------------------+
                     |  CoAP/HTTP        |
                     +-------------------+
                     |IPv6 adaption layer|
                     +-------------------+
                     |  DECT ULE DLC     |
                     +-------------------+
                     |  DECT ULE MAC     |
                     +-------------------+
                     |  DECT ULE PHY     |
                     +-------------------+


                   Figure 2: IPv6 over DECT ULE Stack




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 6LoWPAN Border Router (6LBR)
   and a 6LoWPAN Node (6LN), respectively.  This document does only
   address this primary scenario.

   In DECT ULE, 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.


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


       Figure 3: DECT ULE star topology




   DECT ULE repeaters are not considered in this proposal.





Mariager, et al.        Expires January 16, 2014                [Page 6]

Internet-Draft             IPv6 over DECT ULE                  July 2013


2.3.  Addressing Model

   Each DECT PP is assigned an <IPEI> (International Portable Equipment
   Identity) during manufacturing.  This identity has the size of 40
   bits and is globally unique for the PP and can be used to constitute
   the MAC address.

   When bound to a FP, a PP is assigned a 20 bit TPUI (Temporary
   Portable User Identity) 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> (Radio Fixed Part Identity) 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.

   Alternatively 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.  When such approach, the FP and PP have to implement
   a mapping between used MAC-48 addresses and DECT identities.

2.4.  MTU Considerations

   Generally the DECT ULE FP and PP may be generating data that fits
   into one MAC Layer packet (38 bytes) for periodically transferred
   information, depending on application.  IP data packets may be much
   larger and hence MTU size should be the size of the IP data packet.
   The DECT ULE DLC procedures supports segmentation and reassembly of
   any MTU size below 65536 bytes, but most implementations do only
   support smaller values.

   If an implementation cannot support the sufficient MTU size (due to
   implementation cost) then SAR needs to be supported at upper layers.
   The SAR feature of [RFC4944] section 5 could be considered.

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

   It is important to realize that the support of larger packets will be
   on the expense of battery life, as a large packet will be fragmented
   into several or many MAC layer packets, each consuming power to
   transmit / receive.









Mariager, et al.        Expires January 16, 2014                [Page 7]

Internet-Draft             IPv6 over DECT ULE                  July 2013


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

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

   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 MUST NOT be used in DECT ULE networks.  In addition, a
   DECT ULE PP node MUST NOT play the role of a 6LoWPAN Router (6LR).

3.1.  Protocol stack

   DECT ULE standardization of protocol identifier in negotiation of
   higher layer application protocol 6LoWPAN: xx.  This identifier is
   reserved for 6LoWPAN and has to be standardized by ETSI.

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 FAR functionality and RFC4944 MUST
   NOT be used.Since IPv6 requires MTU size of at least 1280 octets, the
   DECT ULE connection (PVC) must be configured with configured with
   equivalent MTU size.

   This specification also assumes the IPv6 header compression format
   specified in [RFC6282].  It is also assumed that the IPv6 payload
   length can be inferred from the ULE DLC packet length and the IID
   value inferred from the link-layer address.









Mariager, et al.        Expires January 16, 2014                [Page 8]

Internet-Draft             IPv6 over DECT ULE                  July 2013


   Due to DECT ULE star topology, each branch of the star is considered
   to be an individual link and thus the PP cannot directly hear each
   other and also cannot talk to each other with link-local addresses.
   After the FP and PP 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.  IPv6 Address Configuration

   A DECT ULE 6LN performs stateless address autoconfiguration as per
   RFC 4862.  A 64-bit Interface identifier (IID) for a DECT ULE
   interface MAY be formed by utilizing a MAC-48 device address as
   defined in RFC 2464 "IPv6 over Ethernet" specification.
   Alternatively, the DECT device addresses IPEI, RFPI or TPUI, MAY be
   used instead to derive the IID.  In the case of randomly generated
   IID or use of IID derived from DECT devices addresses, the "Universal
   /Local" bit MUST be set to 0.  Only if a global unique MAC-48 is used
   the "Universal/Local" bit can be set to 1.

   As defined in RFC 4291, the IPv6 link-local address for a DECT ULE
   node is formed by appending the IID, to the prefix FE80::/64.

   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 or by using Unique
   Local IPv6 Unicast Addresses (ULA).  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.  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 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.  A DECT ULE 6LN MUST register its address with the 6LBR by sending
   a Neighbor Solicitation (NS) message with the ARO option and process
   the Neighbor Advertisement (NA) accordingly.  The NS with the ARO
   option SHOULD be sent irrespective of whether the IID is derived from
   a unique MAC-48 bit device address, DECT ULE device addresses or the



Mariager, et al.        Expires January 16, 2014                [Page 9]

Internet-Draft             IPv6 over DECT ULE                  July 2013


   IID is a random value that is generated as per the privacy extensions
   for stateless address autoconfiguration [RFC4941].  Although RFC 4941
   [RFC4941] permits the use of deprecated addresses for old
   connections, in this specification we mandate that one interface MUST
   NOT use more than one IID at any one time.

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

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 FP is attached to multiple PPs, the FP cannot do a
   multicast to all the connected PPs.  If the FP needs to send a
   multicast packet to all its PPs, it has to replicate the packet and
   unicast it on each link.  However, this may not be energy-efficient
   and particular care must be taken if the FP is battery-powered.  In
   the opposite direction, a PPs can only transmit data to a single
   destination (i.e. the FP).  Hence, when a PP needs to transmit an
   IPv6 multicast packet, the PP will unicast the corresponding DECT ULE
   packet to the FP.  As described in the linkmodel section FP will not
   forward link-local multicast messages to other PPs connected to the
   FP.

3.2.4.  Header Compression

   Header compression as defined in RFC 6282, 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 RFC
   6282 encoding formats.  The DECT ULE's star topology structure can be
   exploited in order to provide a mechanism for IID compression.  The
   following text describes the principles of IPv6 address compression
   on top of DECT ULE.

   In a link-local communication, both the IPv6 source and destination
   addresses MUST be elided, since the node knows that the packet is
   destined for it even if the packet does not have destination IPv6
   address.  On the other hand, a node SHALL learn the IID of the other
   endpoint of each DECT ULE connection it participates in.  By
   exploiting this information, a node that receives a data channel PDU
   containing an IPv6 packet can infer the corresponding IPv6 source
   address.  A node MUST maintain a Neighbor Cache, in which the entries
   include both the IID of the neighbor and the Device Address that



Mariager, et al.        Expires January 16, 2014               [Page 10]

Internet-Draft             IPv6 over DECT ULE                  July 2013


   identifies the neighbor.  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.

   When a 6LN transmits an IPv6 packet to a remote 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 RFC 6282, 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 DAM=01 (if the context
   covers a 64-bit prefix) or as DAM=11 (if the context covers a full,
   128-bit address).  CID and DAC MUST be set to CID=1 and DAC=1.  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 an IPv6 packet sent by a remote node outside the
   DECT ULE network, 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 SAM=01 (if the context covers a 64-bit prefix) or SAM=11 (if the
   context covers a full, 128-bit address).  CID and SAC MUST be set to
   CID=1 and SAC=1.

3.3.  Internet connectivity scenarios

   In a typical scenario, the DECT ULE network is connected to the
   Internet as shown in the Figure 4.







Mariager, et al.        Expires January 16, 2014               [Page 11]

Internet-Draft             IPv6 over DECT ULE                  July 2013


   A degenerate scenario 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 4: 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 5.


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

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


                      Figure 5: 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.

4.  IANA Considerations

   There are no IANA considerations related to this document.



Mariager, et al.        Expires January 16, 2014               [Page 12]

Internet-Draft             IPv6 over DECT ULE                  July 2013


5.  Security Considerations

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

   DECT ULE communication are secured by encryption and per-message
   authentication through CCM mode (Counter with CBC-MAC) similar to
   RFC3610, which has been defined in the ETSI TC-DECT ULE group.  DECT
   ULE DLC layer implements this per-message authentication and
   encryption to provide link-layer security mechanisms as defined by
   ETSI TC-DECT.

   The underlying algorithm for providing authentication and encryption
   is based on AES128.  Individual authentication key (UAK) for each ULE
   PP are generated during the binding procedure.  Session encryption
   keys are renewed regularly.  DECT ULE PPs do not use any shared
   encryption key.

   The DECT ULE pairing procedure generates a master security key and
   during location registration procedure or when the permanent virtual
   circuit are established, the session security keys are generated.
   The generated security keys are individual for each FP-PP binding,
   hence all PP in a system have different security keys.

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.
   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 has to be standardized by ETSI.

   It is proposed to used ETSI DECT ULE protocol identifier 0x06 =
   6LoWPAN.

7.  Acknowledgements

8.  Normative References

   [ETSI-EN300.175-part1-7]
              , .

   [ETSI-TS102.939-1]
              , .




Mariager, et al.        Expires January 16, 2014               [Page 13]

Internet-Draft             IPv6 over DECT ULE                  July 2013


   [I-D.ietf-6lowpan-hc]
              , .

   [I-D.ietf-6lowpan-nd]
              , .

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC4291]  , .

   [RFC4944]  , .

Authors' Addresses

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

   Email: pm@rtx.dk


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

   Email: jtp@rtx.dk


   Zach Shelby
   Sensinode
   Hallituskatu 13-17D
   FI-90100 Oulu
   Finland

   Email: zach.shelby@sensinode.com











Mariager, et al.        Expires January 16, 2014               [Page 14]


Html markup produced by rfcmarkup 1.108, available from http://tools.ietf.org/tools/rfcmarkup/