< draft-ietf-6lo-dect-ule-07.txt   draft-ietf-6lo-dect-ule-08.txt >
6Lo Working Group P. Mariager 6Lo Working Group P. Mariager
Internet-Draft J. Petersen, Ed. Internet-Draft J. Petersen, Ed.
Intended status: Standards Track RTX A/S Intended status: Standards Track RTX A/S
Expires: April 27, 2017 Z. Shelby Expires: May 26, 2017 Z. Shelby
ARM ARM
M. Van de Logt M. Van de Logt
Gigaset Communications GmbH Gigaset Communications GmbH
D. Barthel D. Barthel
Orange Labs Orange Labs
October 24, 2016 November 22, 2016
Transmission of IPv6 Packets over DECT Ultra Low Energy Transmission of IPv6 Packets over DECT Ultra Low Energy
draft-ietf-6lo-dect-ule-07 draft-ietf-6lo-dect-ule-08
Abstract Abstract
DECT Ultra Low Energy is a low power air interface technology that is DECT Ultra Low Energy is a low power air interface technology that is
defined by the DECT Forum and specified by ETSI. defined by the DECT Forum and specified by ETSI.
The DECT air interface technology has been used world-wide in The DECT air interface technology has been used world-wide in
communication devices for more than 20 years, primarily carrying communication devices for more than 20 years, primarily carrying
voice for cordless telephony but has also been deployed for data voice for cordless telephony but has also been deployed for data
centric services. centric services.
skipping to change at page 2, line 10 skipping to change at page 2, line 10
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on April 27, 2017. This Internet-Draft will expire on May 26, 2017.
Copyright Notice Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the Copyright (c) 2016 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 3, line 19 skipping to change at page 3, line 19
Advanced Technology - internet and quality) is a set of product Advanced Technology - internet and quality) is a set of product
certification and interoperability profiles [CAT-iq] defined by DECT certification and interoperability profiles [CAT-iq] defined by DECT
Forum. DECT Ultra Low Energy (DECT ULE or just ULE) is an air Forum. DECT Ultra Low Energy (DECT ULE or just ULE) is an air
interface technology building on the key fundamentals of traditional interface technology building on the key fundamentals of traditional
DECT / CAT-iq but with specific changes to significantly reduce the DECT / CAT-iq but with specific changes to significantly reduce the
power consumption at the expense of data throughput. DECT ULE power consumption at the expense of data throughput. DECT ULE
devices with requirements on power consumption as specified by ETSI devices with requirements on power consumption as specified by ETSI
in [TS102.939-1] and [TS102.939-2], will operate on special power in [TS102.939-1] and [TS102.939-2], will operate on special power
optimized silicon, but can connect to a DECT Gateway supporting optimized silicon, but can connect to a DECT Gateway supporting
traditional DECT / CAT-iq for cordless telephony and data as well as traditional DECT / CAT-iq for cordless telephony and data as well as
the ULE extensions. DECT terminology operates with two major role the ULE extensions. DECT terminology has two major role definitions:
definitions: The Portable Part (PP) is the power constrained device, The Portable Part (PP) is the power constrained device, while the
while the Fixed Part (FP) is the Gateway or base station. This FP Fixed Part (FP) is the Gateway or base station. This FP may be
may be connected to the Internet. An example of a use case for DECT connected to the Internet. An example of a use case for DECT ULE is
ULE is a home security sensor transmitting small amounts of data (few a home security sensor transmitting small amounts of data (few bytes)
bytes) at periodic intervals through the FP, but is able to wake up at periodic intervals through the FP, but is able to wake up upon an
upon an external event (burglar) and communicate with the FP. external event (burglar) and communicate with the FP. Another
Another example incorporating both DECT ULE as well as traditional example incorporating both DECT ULE as well as traditional CAT-iq
CAT-iq telephony is an elderly pendant (broche) which can transmit telephony is an elderly pendant (brooch) which can transmit periodic
periodic status messages to a care provider using very little status messages to a care provider using very little battery, but in
battery, but in the event of urgency, the elderly person can the event of urgency, the elderly person can establish a voice
establish a voice connection through the pendant to an alarm service. connection through the pendant to an alarm service. It is expected
It is expected that DECT ULE will be integrated into many residential that DECT ULE will be integrated into many residential gateways, as
gateways, as many of these already implements DECT CAT-iq for many of these already implement DECT CAT-iq for cordless telephony.
cordless telephony. DECT ULE can be added as a software option for DECT ULE can be added as a software option for the FP. It is
the FP. It is desirable to consider IPv6 for DECT ULE devices due to desirable to consider IPv6 for DECT ULE devices due to the large
the large address space and well-known infrastructure. This document address space and well-known infrastructure. This document describes
describes how IPv6 is used on DECT ULE links to optimize power while how IPv6 is used on DECT ULE links to optimize power while
maintaining the many benefits of IPv6 transmission. [RFC4944], maintaining the many benefits of IPv6 transmission. [RFC4944],
[RFC6282] and [RFC6775] specify the transmission of IPv6 over IEEE [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. DECT ULE has many characteristics similar to those of IEEE
802.15.4, but also differences. A subset of mechanisms defined for 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 over IEEE 802.15.4 can be applied to the
transmission of IPv6 on DECT ULE links. transmission of IPv6 on DECT ULE links.
This document specifies how to map IPv6 over DECT ULE inspired by This document specifies how to map IPv6 over DECT ULE inspired by
[RFC4944], [RFC6282], [RFC6775] and [RFC7668]. [RFC4944], [RFC6282], [RFC6775] and [RFC7668].
1.1. Requirements Notation 1.1. Requirements Notation
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
1.2. Terms Used 1.2. Terms Used
6CO: 6LoWPAN Context Option [RFC6775] 6CO 6LoWPAN Context Option [RFC6775]
6BBR: 6loWPAN Backbone Router 6BBR 6loWPAN Backbone Router
6LBR: 6LoWPAN Border Router as defined in [RFC6775]. The DECT Fixed 6LBR 6LoWPAN Border Router as defined in [RFC6775]. The DECT Fixed
Part is having this role Part is having this role
6LN: 6LoWPAN Node as defined in [RFC6775]. The DECT Portable part 6LN 6LoWPAN Node as defined in [RFC6775]. The DECT Portable part
is having this role is having this role
6LoWPAN: IPv6 over Low-Power Wireless Personal Area Network 6LoWPAN IPv6 over Low-Power Wireless Personal Area Network
AES128: Advanced Encryption Standard with key size of 128 bits AES128 Advanced Encryption Standard with key size of 128 bits
API: Application Programming Interface API Application Programming Interface
ARO: Address Registration Option [RFC6775] ARO Address Registration Option [RFC6775]
CAT-iq: Cordless Advanced Technology - internet and quality CAT-iq Cordless Advanced Technology - internet and quality
CID: Context Identifier [RFC6775] CID Context Identifier [RFC6775]
DAC: Destination Address Compression DAC Destination Address Compression
DAD: Duplicate Address Detection [RFC4862] DAD Duplicate Address Detection [RFC4862]
DAM: Destination Address Mode DAM Destination Address Mode
DHCPv6: Dynamic Host Configuration Protocol for IPv6 [RFC3315] DHCPv6 Dynamic Host Configuration Protocol for IPv6 [RFC3315]
DLC: Data Link Control DLC Data Link Control
DSAA2: DECT Standard Authentication Algorithm #2 DSAA2 DECT Standard Authentication Algorithm #2
DSC: DECT Standard Cipher DSC DECT Standard Cipher
DSC2: DECT Standard Cipher #2 DSC2 DECT Standard Cipher #2
FDMA: Frequency Division Multiplex FDMA Frequency Division Multiplex
FP: DECT Fixed Part, the gateway FP DECT Fixed Part, the gateway
GAP: Generic Access Profile GAP Generic Access Profile
IID: Interface Identifier IID Interface Identifier
IPEI: International Portable Equipment Identity; (DECT identity) IPEI International Portable Equipment Identity; (DECT identity)
MAC-48: 48 bit global unique MAC address managed by IEEE MAC-48 48 bit global unique MAC address managed by IEEE
MAC: Media Access Control MAC Media Access Control
MTU: Maximum Transmission Unit MTU Maximum Transmission Unit
NBMA: Non-broadcast multi-access NBMA Non-broadcast multi-access
ND: Neighbor Discovery [RFC4861] [RFC6775] ND Neighbor Discovery [RFC4861] [RFC6775]
PDU: Protocol Data Unit PDU Protocol Data Unit
PHY: Physical Layer PHY Physical Layer
PMID: Portable MAC Identity; (DECT identity) PMID Portable MAC Identity; (DECT identity)
PP: DECT Portable Part, typically the sensor node (6LN) PP DECT Portable Part, typically the sensor node (6LN)
PVC: Permanent Virtual Circuit PVC Permanent Virtual Circuit
RFPI: Radio Fixed Part Identity; (DECT identity) RFPI Radio Fixed Part Identity; (DECT identity)
SAC: Source Address Compression SAC Source Address Compression
SAM: Source Address Mode SAM Source Address Mode
TDD: Time Division Duplex TDD Time Division Duplex
TDMA: Time Division Multiplex TDMA Time Division Multiplex
TPUI: Temporary Portable User Identity; (DECT identity) TPUI Temporary Portable User Identity; (DECT identity)
UAK: User Authentication Key, DECT master security key UAK User Authentication Key, DECT master security key
ULA: Unique Local Address [RFC4193] ULA Unique Local Address [RFC4193]
2. DECT Ultra Low Energy 2. DECT Ultra Low Energy
DECT ULE is a low power air interface technology that is designed to DECT ULE is a low power air interface technology that is designed to
support both circuit switched for service, such as voice support both circuit switched services, such as voice communication,
communication, and for packet mode data services at modest data rate. and packet mode data services at modest data rate. This draft is
This draft is only addressing the packet mode data service of DECT only addressing the packet mode data service of DECT ULE.
ULE.
2.1. The DECT ULE Protocol Stack 2.1. The DECT ULE Protocol Stack
The DECT ULE protocol stack consists of the PHY layer operating at The DECT ULE protocol stack contains a PHY layer operating at
frequencies in the 1880 - 1920 MHz frequency band depending on the frequencies in the 1880 - 1920 MHz frequency band depending on the
region and uses a symbol rate of 1.152 Mbps. Radio bearers are region and uses a symbol rate of 1.152 Mbaud. Radio bearers are
allocated by use of FDMA/TDMA/TDD techniques. allocated by use of FDMA/TDMA/TDD techniques.
In its generic network topology, DECT is defined as a cellular In its generic network topology, DECT is defined as a cellular
network technology. However, the most common configuration is a star network technology. However, the most common configuration is a star
network with a single FP defining the network with a number of PP network with a single FP defining the network with a number of PP
attached. The MAC layer supports both traditional DECT circuit mode attached. The MAC layer supports both traditional DECT circuit mode
operation as this is used for services like discovery, pairing, operation as this is used for services like discovery, pairing,
security features etc, and it supports new ULE packet mode operation. security features etc, and it supports new ULE packet mode operation.
The circuit mode features have been reused from DECT. The circuit mode features have been reused from DECT.
skipping to change at page 5, line 51 skipping to change at page 5, line 50
PP side. Depending on power down modes employed in the PP, latency PP side. Depending on power down modes employed in the PP, latency
may occur when initiating sessions from FP side. MAC layer may occur when initiating sessions from FP side. MAC layer
communication can take place using either connection oriented packet communication can take place using either connection oriented packet
transfer with low overhead for short sessions or take place using transfer with low overhead for short sessions or take place using
connection oriented bearers including media reservation. The MAC connection oriented bearers including media reservation. The MAC
layer autonomously selects the radio spectrum positions that are layer autonomously selects the radio spectrum positions that are
available within the band and can rearrange these to avoid available within the band and can rearrange these to avoid
interference. The MAC layer has built-in retransmission procedures interference. The MAC layer has built-in retransmission procedures
in order to improve transmission reliability. in order to improve transmission reliability.
The DECT ULE device will typically incorporate an Application The DECT ULE device will typically incorporate an application
Programmers Interface (API) as well as common elements known as programming interface (API) as well as common elements known as
Generic Access Profile (GAP) for enrolling into the network. The Generic Access Profile (GAP) for enrolling into the network. The
DECT ULE stack establishes a permanent virtual circuit (PVC) for the DECT ULE stack establishes a permanent virtual circuit (PVC) for the
application layers and provides support for a range of different application layers and provides support for a range of different
application protocols. The used application protocol is negotiated application protocols. The used application protocol is negotiated
between the PP and FP when the PVC communication service is between the PP and FP when the PVC communication service is
established. This draft defines 6LoWPAN as one of the possible established. This draft defines 6LoWPAN as one of the possible
protocols to negotiate. protocols to negotiate.
+----------------------------------------+ +----------------------------------------+
| Application Layers | | Application Layers |
skipping to change at page 6, line 33 skipping to change at page 6, line 32
+--------------------+-------------------+ +--------------------+-------------------+
| MAC Layer | | MAC Layer |
+--------------------+-------------------+ +--------------------+-------------------+
| PHY Layer | | PHY Layer |
+--------------------+-------------------+ +--------------------+-------------------+
(C-plane) (U-plane) (C-plane) (U-plane)
Figure 1: DECT ULE Protocol Stack Figure 1: DECT ULE Protocol Stack
Figure 1 above shows the DECT ULE Stack divided into the Control- Figure 1 above shows the DECT ULE Stack divided into the Control-
plane and User-data path, to left and to the right, respectively. plane and User-data plane, to left and to the right, respectively.
The shown entities in the Stack are the (PHY) Physical Layer, (MAC) The shown entities in the Stack are the (PHY) Physical Layer, (MAC)
Media Access Control Layer, (DLC) Data Link Control Layer, (NWK) Media Access Control Layer, (DLC) Data Link Control Layer, (NWK)
Network Layer with subcomponents: (LLME) Lower Layer Management Network Layer with subcomponents: (LLME) Lower Layer Management
Entity, (MM) Mobility Management and (CC) Call Control. Above there Entity, (MM) Mobility Management and (CC) Call Control. Above there
are the typically (API) Application Programmers Interface and are the typically (API) Application Programmers Interface and
application profile specific layers. application profile specific layers.
2.2. Link Layer Roles and Topology 2.2. Link Layer Roles and Topology
A FP is assumed to be less constrained than a PP. Hence, in the A FP is assumed to be less constrained than a PP. Hence, in the
skipping to change at page 7, line 18 skipping to change at page 7, line 17
[DECT ULE PP]-----\ /-----[DECT ULE PP] [DECT ULE PP]-----\ /-----[DECT ULE PP]
\ / \ /
[DECT ULE PP]-------+[DECT ULE FP]+-------[DECT ULE PP] [DECT ULE PP]-------+[DECT ULE FP]+-------[DECT ULE PP]
/ \ / \
[DECT ULE PP]-----/ \-----[DECT ULE PP] [DECT ULE PP]-----/ \-----[DECT ULE PP]
Figure 2: DECT ULE star topology Figure 2: DECT ULE star topology
A significant difference between IEEE 802.15.4 and DECT ULE is that A significant difference between IEEE 802.15.4 and DECT ULE is that
the former supports both star and mesh topology (and requires a the former supports both star and mesh topology (and requires a
routing protocol), whereas DECT ULE in it's primary configuration routing protocol), whereas DECT ULE in its primary configuration does
does not support the formation of multihop networks at the link not support the formation of multihop networks at the link layer. In
layer. In consequence, the mesh header defined in [RFC4944] for mesh consequence, the mesh header defined in [RFC4944] for mesh under
under routing are not used in DECT ULE networks. routing are not used in DECT ULE networks.
DECT ULE repeaters are considered to operate in the DECT protocol DECT ULE repeaters are considered to operate transparently in the
domain and are outside the scope of this document. DECT protocol domain and are outside the scope of this document.
2.3. Addressing Model 2.3. Addressing Model
Each DECT PP is assigned an IPEI during manufacturing. This identity Each DECT PP is assigned an IPEI during manufacturing. This identity
has the size of 40 bits and is globally unique within DECT addressing 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 space and can be used to constitute the MAC address used to derive
the IID for link-local address. the IID for link-local address.
During a DECT location registration procedure, the FP assigns a 20 During a DECT location registration procedure, the FP assigns a 20
bit TPUI to a PP. The FP creates a unique mapping between the bit TPUI to a PP. The FP creates a unique mapping between the
skipping to change at page 8, line 35 skipping to change at page 8, line 34
overhead for mesh addressing. overhead for mesh addressing.
It is important to realize that the usage of larger packets will be 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 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 stack will be fragmented into several or many MAC layer packets, each
consuming power to transmit / receive. The increased MTU size does consuming power to transmit / receive. The increased MTU size does
not change the MAC layer packet and PDU size. not change the MAC layer packet and PDU size.
2.5. Additional Considerations 2.5. Additional Considerations
The DECT ULE standard allows PP to be DECT-registered (bind) to The DECT ULE standard allows PP to be DECT-registered (bound) to
multiple FP and roaming between them. These FP and their 6LBR multiple FP and to roam between them. These FP and their 6LBR
functionalities can either operate individual or connected through a functionalities can either operate individually or connected through
Backbone Router as per [I-D.ietf-6lo-backbone-router]. a Backbone Router as per [I-D.ietf-6lo-backbone-router].
3. Specification of IPv6 over DECT ULE 3. Specification of IPv6 over DECT ULE
Before any IP-layer communications can take place over DECT ULE, DECT 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 ULE enabled nodes such as 6LNs and 6LBRs have to find each other and
establish a suitable link-layer connection. The obtain-access-rights establish a suitable link-layer connection. The obtain-access-rights
registration and location registration procedures are documented by registration and location registration procedures are documented by
ETSI in the specifications [EN300.175-part1-7], [TS102.939-1] and ETSI in the specifications [EN300.175-part1-7], [TS102.939-1] and
[TS102.939-2]. [TS102.939-2].
skipping to change at page 9, line 5 skipping to change at page 9, line 4
ULE enabled nodes such as 6LNs and 6LBRs have to find each other and ULE enabled nodes such as 6LNs and 6LBRs have to find each other and
establish a suitable link-layer connection. The obtain-access-rights establish a suitable link-layer connection. The obtain-access-rights
registration and location registration procedures are documented by registration and location registration procedures are documented by
ETSI in the specifications [EN300.175-part1-7], [TS102.939-1] and ETSI in the specifications [EN300.175-part1-7], [TS102.939-1] and
[TS102.939-2]. [TS102.939-2].
DECT ULE technology sets strict requirements for low power DECT ULE technology sets strict requirements for low power
consumption and thus limits the allowed protocol overhead. 6LoWPAN consumption and thus limits the allowed protocol overhead. 6LoWPAN
standards [RFC4944], [RFC6775], and [RFC6282] provide useful standards [RFC4944], [RFC6775], and [RFC6282] provide useful
functionality for reducing overhead which can be applied to DECT ULE. functionality for reducing overhead which can be applied to DECT ULE.
This functionality comprises link-local IPv6 addresses and stateless This functionality comprises link-local IPv6 addresses and stateless
IPv6 address autoconfiguration, Neighbor Discovery and header IPv6 address autoconfiguration, Neighbor Discovery and header
compression. compression.
The ULE 6LoWPAN adaptation layer can run directly on this U-plane DLC The ULE 6LoWPAN adaptation layer can run directly on this U-plane DLC
layer. Figure 3 illustrates IPv6 over DECT ULE stack. layer. Figure 3 illustrates IPv6 over DECT ULE stack.
As consequence of DECT ULE in it's primary configuration does not Because DECT ULE in its primary configuration does not support the
support the formation of multihop networks at the link layer, the formation of multihop networks at the link layer, the mesh header
mesh header defined in [RFC4944] for mesh under routing MUST NOT be defined in [RFC4944] for mesh under routing MUST NOT be used. In
used. In addition, a DECT ULE PP node MUST NOT play the role of a addition, a DECT ULE PP node MUST NOT play the role of a 6LoWPAN
6LoWPAN Router (6LR). Router (6LR).
3.1. Protocol Stack 3.1. Protocol Stack
In order to enable data transmission over DECT ULE, a Permanent In order to enable data transmission over DECT ULE, a Permanent
Virtual Circuit (PVC) has to be configured and opened between FP and Virtual Circuit (PVC) has to be configured and opened between FP and
PP. This is done by setting up a DECT service call from PP to FP. PP. This is done by setting up a DECT service call between PP and
In DECT protocol domain the PP SHALL specify the <<IWU-ATTRIBUTES>> FP. In DECT protocol domain the PP SHALL specify the <<IWU-
in a service-change (other) message before sending a service-change ATTRIBUTES>> in a service-change (other) message before sending a
(resume) message as defined in [TS102.939-1]. The <<IWU-ATTRIBTES>> service-change (resume) message as defined in [TS102.939-1]. The
SHALL define the ULE Application Protocol Identifier to 0x06 and the <<IWU-ATTRIBTES>> SHALL define the ULE Application Protocol
MTU size to 1280 octets or larger. The FP sends a service-change- Identifier to 0x06 and the MTU size to 1280 octets or larger. The FP
accept (resume) that MUST contain a valid paging descriptor. The PP sends a service-change-accept (resume) that MUST contain a valid
MUST be pageable. Following this, transmission of IPv6 packets can paging descriptor. The PP MUST be pageable. Following this,
start. transmission of IPv6 packets can start.
+-------------------+ +-------------------+
| UDP/TCP/other | | UDP/TCP/other |
+-------------------+ +-------------------+
| IPv6 | | IPv6 |
+-------------------+ +-------------------+
|6LoWPAN adapted to | |6LoWPAN adapted to |
| DECT ULE | | DECT ULE |
+-------------------+ +-------------------+
| DECT ULE DLC | | DECT ULE DLC |
skipping to change at page 11, line 43 skipping to change at page 11, line 43
Section 5.3. Section 5.3.
For non-link-local addresses, 6LNs SHOULD NOT be configured to use For non-link-local addresses, 6LNs SHOULD NOT be configured to use
IIDs derived from a MAC-48 device address or DECT device addresses. IIDs derived from a MAC-48 device address or DECT device addresses.
Alternative schemes such as Cryptographically Generated Addresses Alternative schemes such as Cryptographically Generated Addresses
(CGAs) [RFC3972], privacy extensions [RFC4941], Hash-Based Addresses (CGAs) [RFC3972], privacy extensions [RFC4941], Hash-Based Addresses
(HBAs) [RFC5535], DHCPv6 [RFC3315], or static, semantically opaque (HBAs) [RFC5535], DHCPv6 [RFC3315], or static, semantically opaque
addresses [RFC7217] SHOULD be used by default. See also [I-D.ietf- addresses [RFC7217] SHOULD be used by default. See also [I-D.ietf-
6lo-privacy-considerations] for guidance of needed entropy in IIDs. 6lo-privacy-considerations] for guidance of needed entropy in IIDs.
When generated IID's are not globally unique, Duplicate Address When generated IID's are not globally unique, Duplicate Address
Detection (DAD) [RFC4862] MUST be used. In situations where the Detection (DAD) [RFC4862] MUST be used. In situations where
devices address embedded in the IID are required to support deployment constraints require the device's address to be embedded in
deployment constraints, 6LN MAY form a 64-bit IID by utilizing the the IID, the 6LN MAY form a 64-bit IID by utilizing the MAC-48 device
MAC-48 device address or DECT device addresses. The non-link-local address or DECT device addresses. The non-link-local addresses that
addresses that a 6LN generates MUST be registered with 6LBR as a 6LN generates MUST be registered with 6LBR as described in
described in Section 3.2.2. Section 3.2.2.
The means for a 6LBR to obtain an IPv6 prefix for numbering the DECT 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 ULE network is out of scope of this document, but can be, for
example, accomplished via DHCPv6 Prefix Delegation [RFC3633] or by example, accomplished via DHCPv6 Prefix Delegation [RFC3633] or by
using Unique Local IPv6 Unicast Addresses (ULA) [RFC4193]. Due to 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 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 (L) to zero in the Prefix Information Option [RFC4861]. This will
cause 6LNs to always send packets to the 6LBR, including the case cause 6LNs to always send packets to the 6LBR, including the case
when the destination is another 6LN using the same prefix. when the destination is another 6LN using the same prefix.
3.2.2. Neighbor Discovery 3.2.2. Neighbor Discovery
'Neighbor Discovery Optimization for IPv6 over Low-Power Wireless 'Neighbor Discovery Optimization for IPv6 over Low-Power Wireless
Personal Area Networks (6LoWPANs)' [RFC6775] describes the neighbor Personal Area Networks (6LoWPANs)' [RFC6775] describes the neighbor
discovery approach as adapted for use in several 6LoWPAN topologies, discovery approach as adapted for use in several 6LoWPAN topologies,
including the mesh topology. As DECT ULE is considered not to including the mesh topology. As DECT ULE does not support mesh
support mesh networks, hence only those aspects that apply to a star networks, only those aspects of [RFC6775] that apply to star topology
topology are considered. are considered.
The following aspects of the Neighbor Discovery optimizations The following aspects of the Neighbor Discovery optimizations
[RFC6775] are applicable to DECT ULE 6LNs: [RFC6775] are applicable to DECT ULE 6LNs:
1. For sending Router Solicitations and processing Router 1. For sending Router Solicitations and processing Router
Advertisements the DECT ULE 6LNs MUST, respectively, follow Sections Advertisements the DECT ULE 6LNs MUST, respectively, follow Sections
5.3 and 5.4 of the [RFC6775]. 5.3 and 5.4 of the [RFC6775].
2. A DECT ULE 6LN MUST NOT register its link-local address. Because 2. A DECT ULE 6LN MUST NOT register its link-local address. Because
the IIDs used in link-local addresses are derived from DECT the IIDs used in link-local addresses are derived from DECT
skipping to change at page 16, line 30 skipping to change at page 16, line 30
<-- DECT ULE Cell --> <-- DECT ULE Cell --> <-- DECT ULE Cell --> <-- DECT ULE Cell -->
Figure 7: Multiple DECT ULE cells in a single Multi-Link subnet Figure 7: Multiple DECT ULE cells in a single Multi-Link subnet
4. IANA Considerations 4. IANA Considerations
There are no IANA considerations related to this document. There are no IANA considerations related to this document.
5. Security Considerations 5. Security Considerations
The secure transmission of speech over DECT will be based on the The secure transmission of circuit mode services in DECT is based on
DSAA2 and DSC/DSC2 specification developed by ETSI TC DECT and the the DSAA2 and DSC/DSC2 specifications developed by ETSI TC DECT and
ETSI SAGE Security expert group. the ETSI SAGE Security expert group.
DECT ULE communications are secured at the link-layer (DLC) by DECT ULE communications are secured at the link-layer (DLC) by
encryption and per-message authentication through CCM mode (Counter encryption and per-message authentication through CCM mode (Counter
with CBC-MAC) similar to [RFC3610]. The underlying algorithm for with CBC-MAC) similar to [RFC3610]. The underlying algorithm for
providing encryption and authentication is AES128. providing encryption and authentication is AES128.
The DECT ULE pairing procedure generates a master authentication key The DECT ULE pairing procedure generates a master authentication key
(UAK). During location registration procedure or when the permanent (UAK). During location registration procedure or when the permanent
virtual circuit are established, the session security keys are virtual circuit are established, the session security keys are
generated. Session security keys may be renewed regularly. The generated. Session security keys may be renewed regularly. The
skipping to change at page 17, line 32 skipping to change at page 17, line 32
The ETSI DECT ULE Application Protocol Identifier is specified to The ETSI DECT ULE Application Protocol Identifier is specified to
0x06 for 6LoWPAN [TS102.939-1]. 0x06 for 6LoWPAN [TS102.939-1].
7. Acknowledgements 7. Acknowledgements
We are grateful to the members of the IETF 6lo working group; this We are grateful to the members of the IETF 6lo working group; this
document borrows liberally from their work. document borrows liberally from their work.
Ralph Droms, Samita Chakrabarti, Kerry Lynn, Suresh Krishnan, Pascal Ralph Droms, Samita Chakrabarti, Kerry Lynn, Suresh Krishnan, Pascal
Thubert and Tatuya Jinmei have provided valuable feedback for this Thubert, Tatuya Jinmei and Dale Worley have provided valuable
draft. feedback for this draft.
8. References 8. References
8.1. Normative References 8.1. Normative References
[EN300.175-part1-7] [EN300.175-part1-7]
ETSI, "Digital Enhanced Cordless Telecommunications ETSI, "Digital Enhanced Cordless Telecommunications
(DECT); Common Interface (CI);", March 2015, (DECT); Common Interface (CI);", March 2015,
<https://www.etsi.org/deliver/ <https://www.etsi.org/deliver/
etsi_en/300100_300199/30017501/02.06.01_60/ etsi_en/300100_300199/30017501/02.06.01_60/
skipping to change at page 19, line 26 skipping to change at page 19, line 26
Communications; Part 2: Home Automation Network (phase Communications; Part 2: Home Automation Network (phase
2)", March 2015, <https://www.etsi.org/deliver/ 2)", March 2015, <https://www.etsi.org/deliver/
etsi_ts/102900_102999/10293902/01.01.01_60/ etsi_ts/102900_102999/10293902/01.01.01_60/
ts_10293902v010101p.pdf>. ts_10293902v010101p.pdf>.
8.2. Informative References 8.2. Informative References
[CAT-iq] DECT Forum, "Cordless Advanced Technology - internet and [CAT-iq] DECT Forum, "Cordless Advanced Technology - internet and
quality", January 2016, quality", January 2016,
<http://www.dect.org/userfiles/Public/ <http://www.dect.org/userfiles/Public/
DF_CAT-iq%20Certification%20Overview.pdf>. DF_CAT-iq%20at%20a%20Glance.pdf>.
[I-D.ietf-6lo-backbone-router] [I-D.ietf-6lo-backbone-router]
Thubert, P., "IPv6 Backbone Router", draft-ietf-6lo- Thubert, P., "IPv6 Backbone Router", draft-ietf-6lo-
backbone-router-02 (work in progress), September 2016. backbone-router-02 (work in progress), September 2016.
[I-D.ietf-6lo-privacy-considerations] [I-D.ietf-6lo-privacy-considerations]
Thaler, D., "Privacy Considerations for IPv6 over Networks Thaler, D., "Privacy Considerations for IPv6 Adaptation
of Resource-Constrained Nodes", draft-ietf-6lo-privacy- Layer Mechanisms", draft-ietf-6lo-privacy-
considerations-03 (work in progress), September 2016. considerations-04 (work in progress), October 2016.
[I-D.ietf-6man-default-iids] [I-D.ietf-6man-default-iids]
Gont, F., Cooper, A., Thaler, D., and S. LIU, Gont, F., Cooper, A., Thaler, D., and S. LIU,
"Recommendation on Stable IPv6 Interface Identifiers", "Recommendation on Stable IPv6 Interface Identifiers",
draft-ietf-6man-default-iids-16 (work in progress), draft-ietf-6man-default-iids-16 (work in progress),
September 2016. September 2016.
[RFC3315] Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins, [RFC3315] Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins,
C., and M. Carney, "Dynamic Host Configuration Protocol C., and M. Carney, "Dynamic Host Configuration Protocol
for IPv6 (DHCPv6)", RFC 3315, DOI 10.17487/RFC3315, July for IPv6 (DHCPv6)", RFC 3315, DOI 10.17487/RFC3315, July
 End of changes. 25 change blocks. 
114 lines changed or deleted 114 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/