Internet DRAFT - draft-ietf-6lo-dect-ule
draft-ietf-6lo-dect-ule
6Lo Working Group P. Mariager
Internet-Draft J. Petersen, Ed.
Intended status: Standards Track RTX A/S
Expires: June 18, 2017 Z. Shelby
ARM
M. Van de Logt
Gigaset Communications GmbH
D. Barthel
Orange Labs
December 15, 2016
Transmission of IPv6 Packets over DECT Ultra Low Energy
draft-ietf-6lo-dect-ule-09
Abstract
Digital Enhanced Cordless Telecommunications (DECT) Ultra Low Energy
(ULE) 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 June 18, 2017 [Page 1]
Internet-Draft IPv6 over DECT ULE December 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 June 18, 2017.
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 . . . . . . . . . . . . . . . . . . 4
1.2. Terms Used . . . . . . . . . . . . . . . . . . . . . . . 4
2. DECT Ultra Low Energy . . . . . . . . . . . . . . . . . . . . 6
2.1. The DECT ULE Protocol Stack . . . . . . . . . . . . . . . 6
2.2. Link Layer Roles and Topology . . . . . . . . . . . . . . 7
2.3. Addressing Model . . . . . . . . . . . . . . . . . . . . 8
2.4. MTU Considerations . . . . . . . . . . . . . . . . . . . 9
2.5. Additional Considerations . . . . . . . . . . . . . . . . 9
3. Specification of IPv6 over DECT ULE . . . . . . . . . . . . . 9
3.1. Protocol Stack . . . . . . . . . . . . . . . . . . . . . 10
3.2. Link Model . . . . . . . . . . . . . . . . . . . . . . . 10
3.3. Subnets and Internet Connectivity Scenarios . . . . . . . 15
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
5. Security Considerations . . . . . . . . . . . . . . . . . . . 17
6. ETSI Considerations . . . . . . . . . . . . . . . . . . . . . 18
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 18
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 18
8.1. Normative References . . . . . . . . . . . . . . . . . . 18
8.2. Informative References . . . . . . . . . . . . . . . . . 20
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21
Mariager, et al. Expires June 18, 2017 [Page 2]
Internet-Draft IPv6 over DECT ULE December 2016
1. Introduction
Digital Enhanced Cordless Telecommunications (DECT) 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
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 but with specific changes to significantly reduce the
power consumption at the expense of data throughput. 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 has 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 a pendant (brooch) for the elderly 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 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] 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].
Mariager, et al. Expires June 18, 2017 [Page 3]
Internet-Draft IPv6 over DECT ULE December 2016
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
Mariager, et al. Expires June 18, 2017 [Page 4]
Internet-Draft IPv6 over DECT ULE December 2016
6CO 6LoWPAN Context Option [RFC6775]
6BBR 6loWPAN Backbone Router
6LBR 6LoWPAN Border Router as defined in [RFC6775]. The DECT Fixed
Part is having this role
6LN 6LoWPAN Node as defined in [RFC6775]. The DECT Portable part
is having this role
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
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
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
NBMA Non-broadcast multi-access
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]
Mariager, et al. Expires June 18, 2017 [Page 5]
Internet-Draft IPv6 over DECT ULE December 2016
2. DECT Ultra Low Energy
DECT ULE is a low power air interface technology that is designed to
support both circuit switched services, such as voice communication,
and 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 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
attached. The MAC layer supports both traditional DECT circuit mode
operation as this is used for services like discovery, pairing,
security features etc, and it supports new ULE packet mode operation.
The 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 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 for IPv6 over DECT ULE.
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
programming interface (API) as well as common elements known as
Generic Access Profile (GAP) for enrolling into the network. The
Mariager, et al. Expires June 18, 2017 [Page 6]
Internet-Draft IPv6 over DECT ULE December 2016
DECT ULE stack establishes a 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 0x06 for 6LowPAN. This document
defines the behavior of that 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 and User-data plane, 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 only addresses this primary scenario and all other
scenarios with different roles of FP and PP are out of scope.
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
Mariager, et al. Expires June 18, 2017 [Page 7]
Internet-Draft IPv6 over DECT ULE December 2016
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 (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
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 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 2) in messages between 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].
Each DECT FP is assigned a 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 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
Mariager, et al. Expires June 18, 2017 [Page 8]
Internet-Draft IPv6 over DECT ULE December 2016
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 scheme is NOT RECOMMENDED as per [I-D.ietf-6lo-
privacy-considerations].
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
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 per this specification be configured with a 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 will be fragmented into several or many MAC layer packets, each
consuming power to 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 PP to be DECT-registered (bound) to
multiple FP and to roam between them. These FP and their 6LBR
functionalities can either operate individually or connected through
a Backbone Router as per [I-D.ietf-6lo-backbone-router].
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.
Mariager, et al. Expires June 18, 2017 [Page 9]
Internet-Draft IPv6 over DECT ULE December 2016
The ULE 6LoWPAN adaptation layer can run directly on this U-plane DLC
layer. Figure 3 illustrates IPv6 over DECT ULE 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 FP and
PP. This is done by setting up a DECT service call between PP and
FP. In DECT protocol domain 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
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 3 and DECT ULE MAC+DLC is
layer 2. The DECT ULE already implements fragmentation and
Mariager, et al. Expires June 18, 2017 [Page 10]
Internet-Draft IPv6 over DECT ULE December 2016
reassembly functionality, hence [RFC4944] fragmentation and
reassembly function MUST NOT be used.
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 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 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 address registration information
(see Section 3.2.2).
Due to the DECT ULE star topology (see Section 2.2), each PP has a
separate link to the FP, and 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 avoid the complexity of
implementing separate subnet for each DECT ULE link, a Multi-Link
Subnet model [RFC4903] has been chosen, specifically Non-broadcast
multi-access (NBMA) at 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 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 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 following the
Mariager, et al. Expires June 18, 2017 [Page 11]
Internet-Draft IPv6 over DECT ULE December 2016
guidance in Appendix A of [RFC4291]. However, because DECT and IEEE
address spaces are different, this intermediate address cannot be
considered as unique within IEEE address space. 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.
Globally uniqueness of IID in link-local addresses are 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, 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
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 and [RFC6775]
Section 5.3.
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] for guidance of needed entropy in IIDs
and recommended lifetime of used IIDs. When generated IID's 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 can be, for
example, accomplished via DHCPv6 Prefix Delegation [RFC3633] or by
using Unique Local IPv6 Unicast Addresses (ULA) [RFC4193]. Due to
Mariager, et al. Expires June 18, 2017 [Page 12]
Internet-Draft IPv6 over DECT ULE December 2016
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.
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 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 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, because it does not support the MTU size required by IPv6.
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
Mariager, et al. Expires June 18, 2017 [Page 13]
Internet-Draft IPv6 over DECT ULE December 2016
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 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, DAM=11.
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 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, 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
Mariager, et al. Expires June 18, 2017 [Page 14]
Internet-Draft IPv6 over DECT ULE December 2016
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 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, 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 the DECT ULE star topology (see Section 2.2), PP each have a
separate link to the FP and the FP acts as an IPv6 router rather than
a link-layer switch. A Multi-Link Subnet model [RFC4903] has been
chosen, specifically Non-broadcast multi-access (NBMA) at layer 2 as
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, using one
/64 IPv6 prefix. The 6LBR is acting as router and forwarding packets
between 6LNs and to and from Internet.
6LN
\ ____________
\ / \
6LN ---- 6LBR ------ | Internet |
/ \____________/
/
6LN
<-- One subnet -->
<-- DECT ULE -->
Figure 5: DECT ULE network connected to the Internet
Mariager, et al. Expires June 18, 2017 [Page 15]
Internet-Draft IPv6 over DECT ULE December 2016
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
<---- One subnet ---->
<------ 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.
In other more advanced systems scenarios with multiple FP and 6LBR,
each DECT ULE FP constitutes a wireless cell. The network can be
configured as a Multi-Link 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].
Mariager, et al. Expires June 18, 2017 [Page 16]
Internet-Draft IPv6 over DECT ULE December 2016
____________
/ \
| Internet |
\____________/
|
|
|
|
6BBR/ | 6BBR/
6LN ---- 6LBR -------+------- 6LBR ---- 6LN
/ \ / \
/ \ / \
6LN 6LN 6LN 6LN
<------------------One subnet ------------------>
<-- DECT ULE Cell --> <-- DECT ULE Cell -->
Figure 7: Multiple DECT ULE cells in a single Multi-Link subnet
4. IANA Considerations
There are no IANA considerations related to this document.
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 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. Both the master authentication key and session security
keys are generated by use of the DSAA2 algorithm [EN300.175-part1-7],
which is using AES128 as 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
all PP in a system have different security keys. DECT ULE PPs do not
use any shared encryption key.
Mariager, et al. Expires June 18, 2017 [Page 17]
Internet-Draft IPv6 over DECT ULE December 2016
Even though DECT ULE offers link-layer security, it is still
recommended to use secure transport or application protocols above
6LoWPAN.
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].
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. 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>.
Mariager, et al. Expires June 18, 2017 [Page 18]
Internet-Draft IPv6 over DECT ULE December 2016
[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>.
Mariager, et al. Expires June 18, 2017 [Page 19]
Internet-Draft IPv6 over DECT ULE December 2016
[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%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>.
Mariager, et al. Expires June 18, 2017 [Page 20]
Internet-Draft IPv6 over DECT ULE December 2016
[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>.
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 June 18, 2017 [Page 21]
Internet-Draft IPv6 over DECT ULE December 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 June 18, 2017 [Page 22]
