< draft-ietf-6lo-dect-ule-00.txt   draft-ietf-6lo-dect-ule-01.txt >
6Lo Working Group P. Mariager, Ed. 6Lo Working Group P. Mariager
Internet-Draft J. Petersen Internet-Draft J. Petersen, Ed.
Intended status: Standards Track RTX A/S Intended status: Standards Track RTX A/S
Expires: December 21, 2014 Z. Shelby Expires: July 31, 2015 Z. Shelby
Sensinode ARM
M. Van de Logt M. Van de Logt
Gigaset Communications GmbH Gigaset Communications GmbH
D. Barthel D. Barthel
Orange Labs Orange Labs
June 19, 2014 January 27, 2015
Transmission of IPv6 Packets over DECT Ultra Low Energy Transmission of IPv6 Packets over DECT Ultra Low Energy
draft-ietf-6lo-dect-ule-00 draft-ietf-6lo-dect-ule-01
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 15 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.
The DECT Ultra Low Energy is a recent addition to the DECT interface The DECT Ultra Low Energy is a recent addition to the DECT interface
primarily intended for low-bandwidth, low-power applications such as primarily intended for low-bandwidth, low-power applications such as
sensor devices, smart meters, home automation etc. As the DECT Ultra sensor devices, smart meters, home automation etc. As the DECT Ultra
Low Energy interface inherits many of the capabilities from DECT, it Low Energy interface inherits many of the capabilities from DECT, it
benefits from long range, interference free operation, world wide benefits from long range, interference free operation, world wide
reserved frequency band, low silicon prices and maturity. There is reserved frequency band, low silicon prices and maturity. There is
an added value in the ability to communicate with IPv6 over DECT ULE an added value in the ability to communicate with IPv6 over DECT ULE
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 December 21, 2014. This Internet-Draft will expire on July 31, 2015.
Copyright Notice Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the Copyright (c) 2015 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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Requirements Notation . . . . . . . . . . . . . . . . . . 3 1.1. Requirements Notation . . . . . . . . . . . . . . . . . . 3
1.2. Terms Used . . . . . . . . . . . . . . . . . . . . . . . 3 1.2. Terms Used . . . . . . . . . . . . . . . . . . . . . . . 3
2. DECT Ultra Low Energy . . . . . . . . . . . . . . . . . . . . 4 2. DECT Ultra Low Energy . . . . . . . . . . . . . . . . . . . . 4
2.1. The DECT ULE Protocol Stack . . . . . . . . . . . . . . . 4 2.1. The DECT ULE Protocol Stack . . . . . . . . . . . . . . . 4
2.2. Link layer roles and topology . . . . . . . . . . . . . . 5 2.2. Link layer roles and topology . . . . . . . . . . . . . . 6
2.3. Addressing Model . . . . . . . . . . . . . . . . . . . . 6 2.3. Addressing Model . . . . . . . . . . . . . . . . . . . . 6
2.4. MTU Considerations . . . . . . . . . . . . . . . . . . . 7 2.4. MTU Considerations . . . . . . . . . . . . . . . . . . . 7
2.5. Additional Considerations . . . . . . . . . . . . . . . . 7 2.5. Additional Considerations . . . . . . . . . . . . . . . . 7
3. Specification of IPv6 over DECT ULE . . . . . . . . . . . . . 7 3. Specification of IPv6 over DECT ULE . . . . . . . . . . . . . 7
3.1. Protocol stack . . . . . . . . . . . . . . . . . . . . . 8 3.1. Protocol stack . . . . . . . . . . . . . . . . . . . . . 8
3.2. Link model . . . . . . . . . . . . . . . . . . . . . . . 8 3.2. Link model . . . . . . . . . . . . . . . . . . . . . . . 8
3.3. Internet connectivity scenarios . . . . . . . . . . . . . 12 3.3. Internet connectivity scenarios . . . . . . . . . . . . . 12
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
5. Security Considerations . . . . . . . . . . . . . . . . . . . 13 5. Security Considerations . . . . . . . . . . . . . . . . . . . 13
6. ETSI Considerations . . . . . . . . . . . . . . . . . . . . . 13 6. ETSI Considerations . . . . . . . . . . . . . . . . . . . . . 14
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14
8. Normative References . . . . . . . . . . . . . . . . . . . . 14 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 8.1. Normative References . . . . . . . . . . . . . . . . . . 14
8.2. Informative References . . . . . . . . . . . . . . . . . 15
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16
1. Introduction 1. Introduction
DECT Ultra Low Energy (DECT ULE or just ULE) is an air interface DECT Ultra Low Energy (DECT ULE or just ULE) is an air interface
technology building on the key fundamentals of traditional DECT / technology building on the key fundamentals of traditional DECT /
CAT-iq but with specific changes to significantly reduce the power CAT-iq but with specific changes to significantly reduce the power
consumption on the expense of data throughput. DECT ULE devices with consumption on the expense of data throughput. DECT ULE devices with
requirements to power consumption will operate on special power requirements to power consumption 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
skipping to change at page 4, line 10 skipping to change at page 4, line 10
PP: DECT Portable Part, typically the sensor node PP: DECT Portable Part, typically the sensor node
FP: DECT Fixed Part, the gateway FP: DECT Fixed Part, the gateway
LLME: Lower Layer Management Entity LLME: Lower Layer Management Entity
NWK: Network NWK: Network
PVC: Permanent Virtual Circuit PVC: Permanent Virtual Circuit
FAR: Fragmentation and Reassembly 6LN: DECT Portable part having a role as defined in [RFC6775]
6LBR: DECT Fixed Part having a role as defined in [RFC6775]
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 for service, such as voice
communication, and for packet mode data services at modest data rate. communication, and for packet mode data services at modest data rate.
This draft is only addressing the packet mode data service of DECT This draft is 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
skipping to change at page 4, line 49 skipping to change at page 4, line 51
layer ensures packet integrity and preserves packet order, but layer ensures packet integrity and preserves packet order, but
delivery is based on best effort. delivery is based on best effort.
The current DECT ULE MAC layer standard supports low bandwidth data The current DECT ULE MAC layer standard supports low bandwidth data
broadcast. However the usage of this broadcast service has not yet broadcast. However the usage of this broadcast service has not yet
been standardized for higher layers. This document is not been standardized for higher layers. This document is not
considering usage of this DECT ULE MAC broadcast service in current considering usage of this DECT ULE MAC broadcast service in current
version. version.
In general, communication sessions can be initiated from both FP and In general, communication sessions can be initiated from both FP and
PP side. Depending of 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 either take place using connection oriented packet communication can either take place using 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 Programmers 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 proposes to define 6LoWPAN as one of the established. This draft defines 6LoWPAN as one of the possible
possible protocols to negotiate. protocols to negotiate.
+----------------------------------------+ +----------------------------------------+
| Applications | | Applications |
+----------------------------------------+ +----------------------------------------+
| Generic Access | ULE Profile | | Generic Access | ULE Profile |
| Profile | | | Profile | |
+----------------------------------------+ +----------------------------------------+
| DECT/Service API | ULE Data API | | DECT/Service API | ULE Data API |
+--------------------+-------------------+ +--------------------+-------------------+
| LLME | NWK (MM,CC)| | | LLME | NWK (MM,CC)| |
skipping to change at page 5, line 48 skipping to change at page 6, line 8
Figure 1: DECT ULE Protocol Stack Figure 1: DECT ULE Protocol Stack
The DECT ULE stack can be divided into control (C-plane) and user- 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, data (U-plane) parts shown to the left and to the right in figure 1,
respectively. respectively.
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
primary scenario FP and PP will act as 6LoWPAN Border Router (6LBR) primary scenario FP and PP will act as 6LBR and a 6LN, respectively.
and a 6LoWPAN Node (6LN), respectively. This document does only This document does only address this primary scenario.
address this primary scenario.
In DECT ULE, communication only takes place between a FP and a PP. A In DECT ULE, at link layer the communication only takes place between
FP is able to handle multiple simultaneous connections with a number a FP and a PP. A FP is able to handle multiple simultaneous
of PP. Hence, in a DECT ULE network using IPv6, a radio hop is connections with a number of PP. Hence, in a DECT ULE network using
equivalent to an IPv6 link and vice versa. IPv6, a radio hop is equivalent to an IPv6 link and vice versa.
[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
DECT ULE repeaters are not considered in this proposal. DECT ULE repeaters are not considered in this document.
2.3. Addressing Model 2.3. Addressing Model
Each DECT PP is assigned an <IPEI> (International Portable Equipment Each DECT PP is assigned an <IPEI> (International Portable Equipment
Identity) during manufacturing. This identity has the size of 40 Identity) during manufacturing. This identity has the size of 40
bits and is DECT globally unique for the PP and can be used to bits and is DECT globally unique for the PP and can be used to
constitute the MAC address. However, it can not be used to derive a constitute the MAC address. However, it cannot be used to derive a
globally unique IID. globally unique IID.
When bound to a FP, a PP is assigned a 20 bit TPUI (Temporary 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 Portable User Identity) which is unique within the FP. This TPUI is
used for addressing (layer 2) in messages between FP and PP. used for addressing (layer 2) in messages between FP and PP.
Each DECT FP is assigned a <RFPI> (Radio Fixed Part Identity) during Each DECT FP is assigned a <RFPI> (Radio Fixed Part Identity) during
manufacturing. This identity has the size of 40 bits and is globally 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. unique for a FP and can be used to constitute the MAC address.
However, it can not be used to derive a globally unique IID. However, it cannot be used to derive a globally unique IID.
Alternatively each DECT PP and DECT FP can be assigned a unique Alternatively each DECT PP and DECT FP can be assigned a unique
(IEEE) MAC-48 address additionally to the DECT identities to be used (IEEE) MAC-48 address additionally to the DECT identities to be used
by the 6LoWPAN. With such an approach, the FP and PP have to by the 6LoWPAN. With such an approach, the FP and PP have to
implement a mapping between used MAC-48 addresses and DECT implement a mapping between used MAC-48 addresses and DECT
identities. identities.
2.4. MTU Considerations 2.4. MTU Considerations
Generally the DECT ULE FP and PP may be generating data that fits Generally the DECT ULE FP and PP may be generating data that fits
skipping to change at page 7, line 36 skipping to change at page 7, line 36
2.5. Additional Considerations 2.5. Additional Considerations
The DECT ULE standard allows PP to be registered (bind) to multiple The DECT ULE standard allows PP to be registered (bind) to multiple
FP and roaming between these FP. This draft does not consider the FP and roaming between these FP. This draft does not consider the
scenarios of PP roaming between multiple FP. The use of repeater scenarios of PP roaming between multiple FP. The use of repeater
functionality is also not considered in this draft. functionality is also not considered in this draft.
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
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] and [TS102.939-1].
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.
skipping to change at page 8, line 15 skipping to change at page 8, line 21
DECT ULE PP node MUST NOT play the role of a 6LoWPAN Router (6LR). DECT ULE PP node MUST NOT play the role of a 6LoWPAN Router (6LR).
3.1. Protocol stack 3.1. Protocol stack
In order to enable transmission of IPv6 packets over DECT ULE, a In order to enable transmission of IPv6 packets over DECT ULE, a
Permanent Virtual Circuit (PVC) has to be opened between FP and PP. Permanent Virtual Circuit (PVC) has to be opened between FP and PP.
This MUST be done by setting up a service call from PP to FP. The PP This MUST be done by setting up a service call from PP to FP. The PP
SHALL specify the <<IWU-ATTRIBUTES>> in a service-change (other) SHALL specify the <<IWU-ATTRIBUTES>> in a service-change (other)
message before sending a service-change (resume) message as defined message before sending a service-change (resume) message as defined
in [TS102.939-1]. The <<IWU-ATTRIBTES>> SHALL define the ULE in [TS102.939-1]. The <<IWU-ATTRIBTES>> SHALL define the ULE
Application Protocol Identifier to 0x06 (reserved for 6LoWPAN and has Application Protocol Identifier to 0x06 and the MTU size to 1280
to be standardized by ETSI) and the MTU size to 1280 octets or octets or larger. The FP MUST send a service-change-accept (resume)
larger. The FP MUST send a service-change-accept (resume) containing containing a valid paging descriptor. The PP MUST be pageable.
a valid paging descriptor. The PP MUST be pageable.
+-------------------+ +-------------------+
| 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 8, line 40 skipping to change at page 8, line 45
| DECT ULE MAC | | DECT ULE MAC |
+-------------------+ +-------------------+
| DECT ULE PHY | | DECT ULE PHY |
+-------------------+ +-------------------+
Figure 3: IPv6 over DECT ULE Stack Figure 3: IPv6 over DECT ULE Stack
3.2. Link model 3.2. Link model
The general model is that IPv6 is layer 3 and DECT ULE MAC+DLC is 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] layer 2. The DECT ULE implements fragmentation and reassembly
fragmentation and reassembly function is not needed. Since IPv6 functionality and [RFC4944] fragmentation and reassembly function
requires MTU size of at least 1280 octets, the DECT ULE connection MUST NOT be used. Since IPv6 requires MTU size of at least 1280
(PVC) must be configured with equivalent MTU size. octets, the DECT ULE connection (PVC) MUST be configured with
equivalent MTU size.
This specification also assumes the IPv6 header compression format This specification also assumes the IPv6 header compression format
specified in [RFC6282]. It is also assumed that the IPv6 payload specified in [RFC6282]. It is also assumed that the IPv6 payload
length can be inferred from the ULE DLC packet length and the IID length can be inferred from the ULE DLC packet length and the IID
value inferred from the link-layer address. value inferred from the link-layer address.
Due to DECT ULE star topology, each branch of the star is considered Due to DECT ULE star topology, each branch of the star is considered
to be an individual link and thus the PPs cannot directly hear one to be an individual link and thus the PPs cannot directly hear one
another and also cannot talk to one another with link-local another and cannot talk to one another with link-local addresses.
addresses. After the FP and PPs have connected at the DECT ULE However, the FP acts as a 6LBR for communication between the PPs.
level, the link can be considered up and IPv6 address configuration After the FP and PPs have connected at the DECT ULE level, the link
and transmission can begin. The FP ensures address collisions do not can be considered up and IPv6 address configuration and transmission
occur. can begin. The FP ensures address collisions do not occur.
3.2.1. Stateless address autoconfiguration 3.2.1. Stateless address autoconfiguration
A DECT ULE 6LN performs stateless address autoconfiguration as per A DECT ULE 6LN performs stateless address autoconfiguration as per
[RFC4862]. A 64-bit Interface identifier (IID) for a DECT ULE [RFC4862]. A 64-bit Interface identifier (IID) for a DECT ULE
interface MAY be formed by utilizing a MAC-48 device address as interface MAY be formed by utilizing a MAC-48 device address as
defined in [RFC2464] "IPv6 over Ethernet" specification. defined in [RFC2464] "IPv6 over Ethernet" specification.
Alternatively, the DECT device addresses IPEI, RFPI or TPUI, MAY be Alternatively, the DECT device addresses IPEI, RFPI or TPUI, MAY be
used instead to derive the IID. In the case of randomly generated used instead to derive the IID.
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 [RFC4291], the IPv6 link-local address for a DECT ULE As defined in [RFC4291], the IPv6 link-local address for a DECT ULE
node is formed by appending the IID, to the prefix FE80::/64, as node is formed by appending the IID, to the prefix FE80::/64, as
shown in Figure 4. shown in Figure 4.
10 bits 54 bits 64 bits 10 bits 54 bits 64 bits
+----------+-----------------+----------------------+ +----------+-----------------+----------------------+
|1111111010| zeros | Interface Identifier | |1111111010| zeros | Interface Identifier |
+----------+-----------------+----------------------+ +----------+-----------------+----------------------+
Figure 4: IPv6 link-local address in DECT ULE 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.
For non-link-local addresses a 64-bit IID MAY be formed by utilizing
a MAC-48 device address. Alternatively, a randomly generated IID
(see Section 3.2.2) can be used instead, for example, as discussed in
[I-D.ietf-6man-default-iids]. The non-link-local addresses 6LN
generates must be registered with 6LBR as described in Section 3.2.2.
Only if the device address is known to be a public address the
"Universal/Local" bit can be set to 1 [RFC4291].
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
skipping to change at page 10, line 10 skipping to change at page 10, line 26
'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 is considered not to
support mesh networks, hence only those aspects that apply to a star support mesh networks, hence only those aspects that apply to a star
topology are considered. topology 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. A DECT ULE 6LN MUST register its address with the 6LBR by sending 1. For sending Router Solicitations and processing Router
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, from the DECT ULE device
addresses or the IID is a random value that is generated as per the
privacy extensions for stateless address autoconfiguration [RFC4941].
Although [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 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 SHOULD NOT register its link-local address. A
DECT ULE 6LN MUST register its non-link-local addresses with the 6LBR
by sending a Neighbor Solicitation (NS) message with the Address
Registration Option (ARO) and process the Neighbor Advertisement (NA)
accordingly. The NS with the ARO option MUST be sent irrespective of
the method used to generate the IID. The 6LN MUST register only one
IPv6 address per available IPv6 prefix.
3.2.3. Unicast and Multicast address mapping 3.2.3. Unicast and Multicast address mapping
The DECT MAC layer broadcast service is considered inadequate for IP The DECT MAC layer broadcast service is considered inadequate for IP
multicast. multicast.
Hence traffic is always unicast between two DECT ULE nodes. Even in 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 the case where a 6LBR is attached to multiple 6LNs, the 6LBR cannot
multicast to all the connected PPs. If the FP needs to send a do a multicast to all the connected 6LNs. If the 6LBR needs to send
multicast packet to all its PPs, it has to replicate the packet and a multicast packet to all its 6LNs, it has to replicate the packet
unicast it on each link. However, this may not be energy-efficient and unicast it on each link. However, this may not be energy-
and particular care must be taken if the FP is battery-powered. In efficient and particular care must be taken if the FP is battery-
the opposite direction, a PP can only transmit data to a single powered. In the opposite direction, a 6LN can only transmit data to
destination (i.e. the FP). Hence, when a PP needs to transmit an or through the 6LBR. Hence, when a 6LN needs to transmit an IPv6
IPv6 multicast packet, the PP will unicast the corresponding DECT ULE multicast packet, the 6LN will unicast the corresponding DECT ULE
packet to the FP. As described in the linkmodel section, the FP will packet to the 6LBR. The 6LBR will then forward the multicast packet
not forward link-local multicast messages to other PPs connected to to other 6LNs. To avoid excess of unwanted multicast traffic being
the FP. sent to 6LNs, the 6LBR SHOULD implement MLD Snooping feature
[RFC4541].
3.2.4. Header Compression 3.2.4. Header Compression
Header compression as defined in [RFC6282], which specifies the Header compression as defined in [RFC6282], which specifies the
compression format for IPv6 datagrams on top of IEEE 802.15.4, is 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 REQUIRED in this document as the basis for IPv6 header compression on
top of DECT ULE. All headers MUST be compressed according to top of DECT ULE. All headers MUST be compressed according to
[RFC6282] encoding formats. The DECT ULE's star topology structure [RFC6282] encoding formats. The DECT ULE's star topology structure
can be exploited in order to provide a mechanism for IID compression. and ARO 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.
The following text describes the principles of IPv6 address 3.2.4.1. Link-local Header Compression
compression on top of DECT ULE.
In a link-local communication, both the IPv6 source and destination In a link-local communication terminated at 6LN and 6LBR, both the
addresses MUST be elided [RFC6282], since the node knows that the IPv6 source and destination addresses MUST be elided, since the node
packet is destined for it even if the packet does not have knows that the packet is destined for it even if the packet does not
destination IPv6 address. A node SHALL learn the IID of the other have destination IPv6 address. A node SHALL learn the IID of the
endpoint of each DECT ULE connection it participates in. By other endpoint of each DECT ULE connection it participates in. By
exploiting this information, a node that receives a PDU containing an exploiting this information, a node that receives a PDU containing an
IPv6 packet can infer the corresponding IPv6 source address. A node IPv6 packet can infer the corresponding IPv6 source address. A node
MUST maintain a Neighbor Cache, in which the entries include both the MUST maintain a Neighbor Cache, in which the entries include both the
IID of the neighbor and the Device Address that identifies the IID of the neighbor and the Device Address that identifies the
neighbor. For the type of communication considered in this neighbor. For the type of communication considered in this
paragraph, the following settings MUST be used in the IPv6 compressed paragraph, the following settings MUST be used in the IPv6 compressed
header: CID=0, SAC=0, SAM=11, DAC=0, DAM=11. header: CID=0, SAC=0, SAM=11, DAC=0, DAM=11.
When a 6LN transmits an IPv6 packet to a remote destination using 3.2.4.2. Non-link-local Header Compression
global Unicast IPv6 addresses, if a context is defined for the prefix
of the 6LNs global IPv6 address, the 6LN MUST indicate this context To enable efficient header compression, the 6LBR MUST include 6LoWPAN
in the corresponding source fields of the compressed IPv6 header as Context Option (6CO) [RFC6775] for all prefixes the 6LBR advertises
per Section 3.1 of [RFC6282], and MUST elide the IPv6 source address. in Router Advertisements for use in stateless address
autoconfiguration.
When a 6LN transmits an IPv6 packet to a destination using global
Unicast IPv6 addresses, if a context is defined for the prefix of the
6LNs global IPv6 address, the 6LN MUST indicate this context in the
corresponding source fields of the compressed IPv6 header as per
Section 3.1 of [RFC6282], and MUST elide the IPv6 source address.
For this, the 6LN MUST use the following settings in the IPv6 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 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 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 assigned the prefix to the 6LNs; and 2) the 6LBR maintains a Neighbor
Cache that relates the Device Address and the IID of the Cache that relates the Device Address and the IID of the
corresponding PP. If a context is defined for the IPv6 destination corresponding PP. If a context is defined for the IPv6 destination
address, the 6LN MUST also indicate this context in the corresponding address, the 6LN MUST also indicate this context in the corresponding
destination fields of the compressed IPv6 header, and MUST elide the destination fields of the compressed IPv6 header, and MUST elide the
prefix of the destination IPv6 address. For this, the 6LN MUST set 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 the DAM field of the compressed IPv6 header as CID=1, DAC=1 and
covers a 64-bit prefix) or as DAM=11 (if the context covers a full, DAM=01 or DAM=11. Note that when a context is defined for the IPv6
128-bit address). CID and DAC MUST be set to CID=1 and DAC=1. Note destination address, the 6LBR can infer the elided destination prefix
that when a context is defined for the IPv6 destination address, the by using the context.
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 When a 6LBR receives a IPv6 packet having a global Unicast IPv6
DECT ULE network, and the destination of the packet is a 6LN, if a address, and the destination of the packet is a 6LN, if a context is
context is defined for the prefix of the 6LN's global IPv6 address, defined for the prefix of the 6LN's global IPv6 address, the 6LBR
the 6LBR MUST indicate this context in the corresponding destination MUST indicate this context in the corresponding destination fields of
fields of the compressed IPv6 header, and MUST elide the IPv6 the compressed IPv6 header, and MUST elide the IPv6 destination
destination address of the packet before forwarding it to the 6LN. address of the packet before forwarding it to the 6LN. For this, the
For this, the 6LBR MUST set the DAM field of the IPv6 compressed 6LBR MUST set the DAM field of the IPv6 compressed header as DAM=11.
header as DAM=11. CID and DAC MUST be set to CID=1 and DAC=1. If a CID and DAC MUST be set to CID=1 and DAC=1. If a context is defined
context is defined for the prefix of the IPv6 source address, the for the prefix of the IPv6 source address, the 6LBR MUST indicate
6LBR MUST indicate this context in the source fields of the this context in the source fields of the compressed IPv6 header, and
compressed IPv6 header, and MUST elide that prefix as well. For MUST elide that prefix as well. For this, the 6LBR MUST set the SAM
this, the 6LBR MUST set the SAM field of the IPv6 compressed header field of the IPv6 compressed header as CID=1, SAC=1 and SAM=01 or
as SAM=01 (if the context covers a 64-bit prefix) or SAM=11 (if the SAM=11.
context covers a full, 128-bit address). CID and SAC MUST be set to
CID=1 and SAC=1.
3.3. Internet connectivity scenarios 3.3. Internet connectivity scenarios
In a typical scenario, the DECT ULE network is connected to the In a typical scenario, the DECT ULE network is connected to the
Internet as shown in the Figure 5. Internet as shown in the Figure 5.
A degenerate scenario can be imagined where a PP is acting as 6LBR A degenerate scenario can be imagined where a PP is acting as 6LBR
and providing Internet connectivity for the FP. How the FP could and providing Internet connectivity for the FP. How the FP could
then further provide Internet connectivity to other PP, possibly then further provide Internet connectivity to other PP, possibly
connected to the FP, is out of the scope of this document. connected to the FP, is out of the scope of this document.
skipping to change at page 13, line 17 skipping to change at page 13, line 32
different PP, the FP has to act as 6LBR, number the network with ULA different PP, the FP has to act as 6LBR, number the network with ULA
prefix [RFC4193], and route packets between PP. prefix [RFC4193], and route packets between PP.
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 speech over DECT will be based on the
DSAA2 and DSC2 work being developed by the DF Security group / ETSI DSAA2 and DSC2 work developed by the DF Security group / ETSI TC DECT
TC DECT and the ETSI SAGE Security expert group. and 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) and during location registration procedure or when the (UAK) and during location registration procedure or when the
permanent virtual circuit are established, the session security keys permanent virtual circuit are established, the session security keys
are generated. Session security keys may be renewed regularly. The are generated. Session security keys may be renewed regularly. The
generated security keys (UAK and session security keys) are generated security keys (UAK and session security keys) are
individual for each FP-PP binding, hence all PP in a system have individual for each FP-PP binding, hence all PP in a system have
different security keys. DECT ULE PPs do not use any shared different security keys. DECT ULE PPs do not use any shared
encryption key. encryption key.
The IPv6 address configuration as described in Section 3.2.1 allows
implementations the choice to support [I-D.ietf-6man-default-iids]
for non-link addresses.
6. ETSI Considerations 6. ETSI Considerations
ETSI is standardizing a list of known application layer protocols ETSI is standardizing a list of known application layer protocols
that can use the DECT ULE permanent virtual circuit packet data that can use the DECT ULE permanent virtual circuit packet data
service. Each protocol is identified by a unique known identifier, service. Each protocol is identified by a unique known identifier,
which is exchanged in the service-change procedure as defined in which is exchanged in the service-change procedure as defined in
[TS102.939-1]. The IPv6/6LoWPAN as described in this document is [TS102.939-1]. The IPv6/6LoWPAN as described in this document is
considered as an application layer protocol on top of DECT ULE. In considered as an application layer protocol on top of DECT ULE. In
order to provide interoperability between 6LoWPAN / DECT ULE devices order to provide interoperability between 6LoWPAN / DECT ULE devices
a common protocol identifier for 6LoWPAN has to be standardized by a common protocol identifier for 6LoWPAN is standardized by ETSI.
ETSI.
It is proposed to use ETSI DECT ULE Application Protocol Identifier The ETSI DECT ULE Application Protocol Identifier is specified to
equal 0x06 for 6LoWPAN. 0x06 for 6LoWPAN.
7. Acknowledgements 7. Acknowledgements
8. Normative References We are grateful to the members of the IETF 6lo working group; this
document borrows liberally from their work.
Ralph Droms has provided valuable feedback for this draft.
8. 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);", August 2013. (DECT); Common Interface (CI);", August 2013.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2464] Crawford, M., "Transmission of IPv6 Packets over Ethernet [RFC2464] Crawford, M., "Transmission of IPv6 Packets over Ethernet
Networks", RFC 2464, December 1998. Networks", RFC 2464, December 1998.
skipping to change at page 14, line 32 skipping to change at page 15, line 8
[RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic [RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic
Host Configuration Protocol (DHCP) version 6", RFC 3633, Host Configuration Protocol (DHCP) version 6", RFC 3633,
December 2003. December 2003.
[RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast
Addresses", RFC 4193, October 2005. Addresses", RFC 4193, October 2005.
[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing
Architecture", RFC 4291, February 2006. Architecture", RFC 4291, February 2006.
[RFC4541] Christensen, M., Kimball, K., and F. Solensky,
"Considerations for Internet Group Management Protocol
(IGMP) and Multicast Listener Discovery (MLD) Snooping
Switches", RFC 4541, May 2006.
[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
"Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,
September 2007. September 2007.
[RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless
Address Autoconfiguration", RFC 4862, September 2007. Address Autoconfiguration", RFC 4862, September 2007.
[RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy [RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy
Extensions for Stateless Address Autoconfiguration in Extensions for Stateless Address Autoconfiguration in
IPv6", RFC 4941, September 2007. IPv6", RFC 4941, September 2007.
skipping to change at page 15, line 16 skipping to change at page 15, line 43
"Neighbor Discovery Optimization for IPv6 over Low-Power "Neighbor Discovery Optimization for IPv6 over Low-Power
Wireless Personal Area Networks (6LoWPANs)", RFC 6775, Wireless Personal Area Networks (6LoWPANs)", RFC 6775,
November 2012. November 2012.
[TS102.939-1] [TS102.939-1]
ETSI, "Digital Enhanced Cordless Telecommunications ETSI, "Digital Enhanced Cordless Telecommunications
(DECT); Ultra Low Energy (ULE); Machine to Machine (DECT); Ultra Low Energy (ULE); Machine to Machine
Communications; Part 1: Home Automation Network (phase Communications; Part 1: Home Automation Network (phase
1)", April 2013. 1)", April 2013.
8.2. Informative References
[I-D.ietf-6man-default-iids]
Gont, F., Cooper, A., Thaler, D., and W. Will,
"Recommendation on Stable IPv6 Interface Identifiers",
draft-ietf-6man-default-iids-02 (work in progress),
January 2015.
Authors' Addresses Authors' Addresses
Peter B. Mariager (editor) Peter B. Mariager
RTX A/S RTX A/S
Stroemmen 6 Stroemmen 6
DK-9400 Noerresundby DK-9400 Noerresundby
Denmark Denmark
Email: pm@rtx.dk Email: pm@rtx.dk
Jens Toftgaard Petersen Jens Toftgaard Petersen (editor)
RTX A/S RTX A/S
Stroemmen 6 Stroemmen 6
DK-9400 Noerresundby DK-9400 Noerresundby
Denmark Denmark
Email: jtp@rtx.dk Email: jtp@rtx.dk
Zach Shelby Zach Shelby
Sensinode Sensinode
Hallituskatu 13-17D 150 Rose Orchard
FI-90100 Oulu San Jose, CA 95134
Finland USA
Email: zach.shelby@sensinode.com Email: zach.shelby@arm.com
Marco van de Logt Marco van de Logt
Gigaset Communications GmbH Gigaset Communications GmbH
Frankenstrasse 2 Frankenstrasse 2
D-46395 Bocholt D-46395 Bocholt
Germany Germany
Email: marco.van-de-logt@gigaset.com Email: marco.van-de-logt@gigaset.com
Dominique Barthel Dominique Barthel
Orange Labs Orange Labs
Email: dominique.barthel@orange.com Email: dominique.barthel@orange.com
 End of changes. 45 change blocks. 
113 lines changed or deleted 160 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/