One document matched: draft-ietf-6lo-dect-ule-04.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY RFC2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY RFC2464 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2464.xml">
<!ENTITY RFC3315 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3315.xml">
<!ENTITY RFC3610 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3610.xml">
<!ENTITY RFC3633 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3633.xml">
<!ENTITY RFC3972 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3972.xml">
<!ENTITY RFC4193 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4193.xml">
<!ENTITY RFC4861 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4861.xml">
<!ENTITY RFC4862 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4862.xml">
<!ENTITY RFC4941 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4941.xml">
<!ENTITY RFC4944 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4944.xml">
<!ENTITY RFC5535 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5535.xml">
<!ENTITY RFC6282 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6282.xml">
<!ENTITY RFC4291 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4291.xml">
<!ENTITY RFC6775 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6775.xml">
<!ENTITY RFC7136 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.7136.xml">
<!ENTITY RFC7217 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.7217.xml">
<!ENTITY RFC7668 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.7668.xml">
<!ENTITY I-D.ietf-6man-default-iids SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-6man-default-iids.xml">
]>
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
<!-- used by XSLT processors -->
<!-- OPTIONS, known as processing instructions (PIs) go here. -->
<!-- For a complete list and description of PIs,
please see http://xml.resource.org/authoring/README.html. -->
<!-- Below are generally applicable PIs that most I-Ds might want to use. -->
<?rfc strict="yes" ?>
<!-- give errors regarding ID-nits and DTD validation -->
<!-- control the table of contents (ToC): -->
<?rfc toc="yes"?>
<!-- generate a ToC -->
<?rfc tocdepth="2"?>
<!-- the number of levels of subsections in ToC. default: 3 -->
<!-- control references: -->
<?rfc symrefs="yes"?>
<!-- use symbolic references tags, i.e, [RFC2119] instead of [1] -->
<?rfc sortrefs="yes" ?>
<!-- sort the reference entries alphabetically -->
<!-- control vertical white space:
(using these PIs as follows is recommended by the RFC Editor) -->
<?rfc compact="yes" ?>
<!-- do not start each main section on a new page -->
<?rfc subcompact="no" ?>
<!-- keep one blank line between list items -->
<!-- end of popular PIs -->
<rfc category="std" docName="draft-ietf-6lo-dect-ule-04" ipr="trust200902">
<front>
<title abbrev="IPv6 over DECT ULE">Transmission of IPv6 Packets over DECT
Ultra Low Energy</title>
<author fullname="Peter B. Mariager" initials="P.M." surname="Mariager">
<organization abbrev="RTX A/S">RTX A/S</organization>
<address>
<postal>
<street>Stroemmen 6</street>
<code>DK-9400 Noerresundby</code>
<country>Denmark</country>
</postal>
<email>pm@rtx.dk</email>
</address>
</author>
<author fullname="Jens Toftgaard Petersen" initials="J.T.P." role="editor"
surname="Petersen">
<organization abbrev="RTX A/S">RTX A/S</organization>
<address>
<postal>
<street>Stroemmen 6</street>
<code>DK-9400 Noerresundby</code>
<country>Denmark</country>
</postal>
<email>jtp@rtx.dk</email>
</address>
</author>
<author fullname="Zach Shelby" initials="Z.S." surname="Shelby">
<organization abbrev="ARM">ARM</organization>
<address>
<postal>
<street>150 Rose Orchard</street>
<code>San Jose, CA 95134</code>
<country>USA</country>
</postal>
<email>zach.shelby@arm.com</email>
</address>
</author>
<author fullname="Marco van de Logt" initials="M.L." surname="Van de Logt">
<organization abbrev="Gigaset Communications GmbH">Gigaset
Communications GmbH</organization>
<address>
<postal>
<street>Frankenstrasse 2</street>
<code>D-46395 Bocholt</code>
<country>Germany</country>
</postal>
<email>marco.van-de-logt@gigaset.com</email>
</address>
</author>
<author fullname="Dominique Barthel" initials="D" surname="Barthel">
<organization>Orange Labs</organization>
<address>
<postal>
<street>28 chemin du Vieux Chene</street>
<code>38243 Meylan</code>
<country>France</country>
</postal>
<email>dominique.barthel@orange.com</email>
</address>
</author>
<date year="2016"/>
<!-- <area/> -->
<workgroup>6Lo Working Group</workgroup>
<!-- <keyword/> -->
<!-- <keyword/> -->
<!-- <keyword/> -->
<!-- <keyword/> -->
<abstract>
<t>DECT Ultra Low Energy is a low power air interface technology that is
defined by the DECT Forum and specified by ETSI.</t>
<t>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.</t>
<t>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.</t>
<t>This document describes how IPv6 is transported over DECT ULE using
6LoWPAN techniques.</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t>DECT Ultra Low Energy (DECT ULE or just ULE) is an air interface
technology building on the key fundamentals of traditional DECT / CAT-iq
but with specific changes to significantly reduce the power consumption
at the expense of data throughput. DECT (Digital Enhanced Cordless
Telecommunications) is a standard series [EN300.175-part1-7] specificed
by ETSI and CAT-iq (Cordless Advanced Technology - internet and quality)
is a set of product certication and interoperability profiles [CAT-iq]
defined by DECT Forum. DECT ULE devices with requirements on power
consumption as specified by ETSI in [TS102.939-1] and [TS102.939-2],
will operate on special power optimized silicon, but can connect to a
DECT Gateway supporting traditional DECT / CAT-iq for cordless telephony
and data as well as the ULE extensions. DECT terminology operates with
two major role definitions: The Portable Part (PP) is the power
constrained device, while the Fixed Part (FP) is the Gateway or base
station. This FP may be connected to the Internet. An example of a use
case for DECT ULE is a home security sensor transmitting small amounts
of data (few bytes) at periodic intervals through the FP, but is able to
wake up upon an external event (burglar) and communicate with the FP.
Another example incorporating both DECT ULE as well as traditional
CAT-iq telephony is an elderly pendant (broche) which can transmit
periodic status messages to a care provider using very little battery,
but in the event of urgency, the elderly person can establish a voice
connection through the pendant to an alarm service. It is expected that
DECT ULE will be integrated into many residential gateways, as many of
these already implements DECT CAT-iq for cordless telephony. DECT ULE
can be added as a software option for the FP. It is desirable to
consider IPv6 for DECT ULE devices due to the large address space and
well-known infrastructure. This document describes how IPv6 is used on
DECT ULE links to optimize power while maintaining the many benefits of
IPv6 transmission. [RFC4944], [RFC6282] and [RFC6775] specify the
transmission of IPv6 over IEEE 802.15.4. DECT ULE has many
characteristics similar to those of IEEE 802.15.4, but also differences.
A subset of mechanisms defined for transmission of IPv6 over IEEE
802.15.4 can be applied to the transmission of IPv6 on DECT ULE
links.</t>
<t>This document specifies how to map IPv6 over DECT ULE inspired by
[RFC4944], [RFC6282], [RFC6775] and [RFC7668].</t>
<section title="Requirements Notation">
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in <xref
target="RFC2119"/>.</t>
</section>
<section title="Terms Used">
<t><figure>
<artwork>
6CO: 6LoWPAN Context Option [RFC6775]
6LBR: DECT Fixed Part having a role as defined in [RFC6775]
6LN: DECT Portable part having a role as defined in [RFC6775]
6LoWPAN: IPv6 over Low-Power Wireless Personal Area Network
AES128: Advanced Encryption Standard with key size of 128 bits
API: Application Programming Interface
ARO: Address Registration Option [RFC6775]
CAT-iq: Corless Advanced Technologi - internet and quality
CID: Context Identifier [RFC6775]
DAC: Destination Address Compression
DAM: Destination Address Mode
DHCPv6: Dynamic Host Configuration Protocol for IPv6 [RFC3315]
DLC: Data Link Control
DSAA2: DECT Standard Authentication Algorithm #2
DSC: DECT Standard Cipher
DSC2: DECT Standard Cipher #2
FDMA: Frequency Division Multiplex
FP: DECT Fixed Part, the gateway
GAP: Generic Access Profile
IID: Interface Identifier
IPEI: International Portable Equipment Identity; (DECT identity)
MAC-48: 48 bit global unique MAC address managed by IEEE
MAC: Media Access Control
MTU: Maximum Transmission Unit
ND: Neighbor Discovery [RFC4861] [RFC6775]
PDU: Protocol Data Unit
PHY: Physical Layer
PMID: Portable MAC Identity; (DECT identity)
PP: DECT Portable Part, typically the sensor node (6LN)
PVC: Permanent Virtual Circuit
RFPI: Radio Fixed Part Identity; (DECT identity)
SAC: Source Address Compression
SAM: Source Address Mode
TDD: Time Division Duplex
TDMA: Time Division Multiplex
TPUI: Temporary Portable User Identity; (DECT identity)
UAK: User Authentication Key, DECT master security key
ULA: Unique Local Address [RFC4193]
</artwork>
</figure></t>
</section>
</section>
<section title="DECT Ultra Low Energy">
<t>DECT ULE is a low power air interface technology that is designed to
support both circuit switched for service, such as voice communication,
and for packet mode data services at modest data rate. This draft is
only addressing the packet mode data service of DECT ULE.</t>
<section title="The DECT ULE Protocol Stack">
<t>The DECT ULE protocol stack consists of the PHY layer operating at
frequencies in the 1880 - 1920 MHz frequency band depending on the
region and uses a symbol rate of 1.152 Mbps. Radio bearers are
allocated by use of FDMA/TDMA/TDD technics.</t>
<t>In its generic network topology, DECT is defined as a cellular
network technology. However, the most common configuration is a star
network with a single FP defining the network with a number of PP
attached. The MAC layer supports both traditional DECT as this is used
for services like discovery, pairing, security features etc. All these
features have been reused from DECT.</t>
<t>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.</t>
<t>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.</t>
<t>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.</t>
<t>The DECT ULE device will typically incorporate an Application
Programmers Interface (API) as well as common elements known as
Generic Access Profile (GAP) for enrolling into the network. The DECT
ULE stack establishes a permanent virtual circuit (PVC) for the
application layers and provides support for a range of different
application protocols. The used application protocol is negotiated
between the PP and FP when the PVC communication service is
established. This draft defines 6LoWPAN as one of the possible
protocols to negotiate.</t>
<t><figure>
<artwork>
+----------------------------------------+
| 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
</artwork>
</figure>Figure 1 above shows the DECT ULE Stack divided into the
Control-plane and User-data path, to left and to the right,
respectively. The shown entities in the Stack are the (PHY) Physical
Layer, (MAC) Media Access Control Layer, (DLC) Data Link Control
Layer, (NWK) Network Layer with subcomponents: (LLME) Lower Layer
Management Entity, (MM) Mobility Management and (CC) Call Control.
Aboves there are the typically (API) Application Programmers Interface
and application profile specific layers.</t>
<t> </t>
</section>
<section title="Link layer roles and topology">
<t>A FP is assumed to be less constrained than a PP. Hence, in the
primary scenario FP and PP will act as 6LBR and a 6LN, respectively.
This document does only address this primary scenario.</t>
<t>In DECT ULE, at link layer the communication only takes place
between a FP and a PP. A FP is able to handle multiple simultaneous
connections with a number of PP. Hence, in a DECT ULE network using
IPv6, a radio hop is equivalent to an IPv6 link and vice versa.
<figure>
<artwork>
[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
</artwork>
</figure></t>
<t>A significant difference between IEEE 802.15.4 and DECT ULE is that
the former supports both star and mesh topology (and requires a
routing protocol), whereas DECT ULE in it's primary configuration does
not support the formation of multihop networks at the link layer. In
consequence, the mesh header defined in [RFC4944] for mesh under
routing are not used in DECT ULE networks.</t>
<t>DECT ULE repeaters are not considered in this document.</t>
<t/>
</section>
<section title="Addressing Model">
<t>Each DECT PP is assigned an IPEI during manufacturing. This
identity has the size of 40 bits and is DECT globally unique for the
PP and can be used to constitute the MAC address. However, it cannot
be used to derive a globally unique IID.</t>
<t>When bound to a FP, a PP is assigned a 20 bit TPUI which is unique
within the FP. This TPUI is used for addressing (layer 2) in messages
between FP and PP.</t>
<t>Each DECT FP is assigned a RFPI during manufacturing. This identity
has the size of 40 bits and is globally unique for a FP and can be
used to constitute the MAC address used to derive the IID for
link-local address. However, it cannot be used to derive a globally
unique IID.</t>
<t>Optionally each DECT PP and DECT FP can be assigned a unique (IEEE)
MAC-48 address additionally to the DECT identities to be used by the
6LoWPAN. During the address registration of non-link-local addresses
as specified by this document, the FP and PP can use such MAC-48 to
construct the IID.</t>
<t/>
</section>
<section title="MTU Considerations">
<t>Idially 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 supports segmentation and
reassembly of any MTU size below 65536 octets, but the default MTU
size defined in DECT ULE [TS102.939-1] is 500 octets. In order to
support complete IP packets, the DLC layer of DECT ULE SHALL per this
specification be configured with a MTU size that fits the requirements
from IPv6 data packets, hence [RFC4944] fragmentation/reassembly is
not required.</t>
<t>It is expected that the LOWPAN_IPHC packet will fulfill all the
requirements for header compression without spending unnecessary
overhead for mesh addressing.</t>
<t>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.</t>
<t/>
</section>
<section title="Additional Considerations">
<t>The DECT ULE standard allows PP to be registered (bind) to multiple
FP and roaming between these FP. This draft does not consider the
scenarios of PP roaming between multiple FP. The use of repeater
functionality is also not considered in this draft.</t>
</section>
</section>
<section title="Specification of IPv6 over DECT ULE">
<t>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].</t>
<t>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.</t>
<t>The ULE 6LoWPAN adaptation layer can run directly on this U-plane DLC
layer. Figure 3 illustrates IPv6 over DECT ULE stack.</t>
<t>As consequence of DECT ULE in it's primary configuration does not
support the formation of multihop networks at the link layer, the mesh
header defined in [RFC4944] for mesh under routing MUST NOT be used. In
addition, a DECT ULE PP node MUST NOT play the role of a 6LoWPAN Router
(6LR).</t>
<section title="Protocol stack">
<t>In order to enable transmission of IPv6 packets over DECT ULE, a
Permanent Virtual Circuit (PVC) has to be opened between FP and PP.
This MUST be done by setting up a service call from PP to FP. The PP
SHALL specify the <<IWU-ATTRIBUTES>> in a service-change
(other) message before sending a service-change (resume) message as
defined in [TS102.939-1]. The <<IWU-ATTRIBTES>> SHALL
define the ULE Application Protocol Identifier to 0x06 and the MTU
size to 1280 octets or larger. The FP MUST send a
service-change-accept (resume) containing a valid paging descriptor.
The PP MUST be pageable.</t>
<t><figure>
<artwork> +-------------------+
| 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
</artwork>
</figure></t>
</section>
<section title="Link model">
<t>The general model is that IPv6 is layer 3 and DECT ULE MAC+DLC is
layer 2. The DECT ULE implements already fragmentation and reassembly
functionality, hence [RFC4944] fragmentation and reassembly function
MUST NOT be used. The DECT ULE DLC link (PVC) MUST be configured with
a minimum MTU size of at least 1280 octers in order to meet the size
requirements of IPv6.</t>
<t>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).</t>
<t>Due to DECT ULE star topology, each branch of the star is
considered to be an individual link and thus the PPs cannot directly
hear one another and cannot talk to one another with link-local
addresses. However, the FP acts as a 6LBR for communication between
the PPs. After the FP and PPs have connected at the DECT ULE level,
the link can be considered up and IPv6 address configuration and
transmission can begin. The FP ensures address collisions do not
occur.</t>
<t/>
<section title="Stateless address autoconfiguration">
<t>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.</t>
<t>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. </t>
<t>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. Least significant bit of this address is the
last bit in network order. First bit is set to a one for addresses
derived from the RFPI and first bit is set to zero for addresses
derived from the IPEI. From these intermediate 48 bit addresses are
derived 64 bit IIDs accordig to the guidance of [RFC4291]. In the
derived IIDs the 7th bit is set to one to indicate that the
addresses are not global unique. For example from
RFPI=11.22.33.44.55 the derived IID is 82:11:22:FF:FE:33:44:55 and
from IPEI=01.23.45.67.89 the derived IID is 02:01:23:FF:FE:45:67:89.
</t>
<t>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.</t>
<t><figure>
<artwork>
10 bits 54 bits 64 bits
+----------+-----------------+----------------------+
|1111111010| zeros | Interface Identifier |
+----------+-----------------+----------------------+
Figure 4: IPv6 link-local address in DECT ULE
</artwork>
</figure></t>
<t>A 6LN MUST join the all-nodes multicast address.</t>
<t>After link-local address configuration, 6LN sends Router
Solicitation messages as described in [RFC4861] Section 6.3.7.</t>
<t>For non-link-local addresses, 6LNs SHOULD NOT be configured to
use IIDs derived from a MAC-48 device address or DECT device
addresses. Alternative schemes such as Cryptographically Generated
Addresses (CGAs) [RFC3972], privacy extensions [RFC4941], Hash-Based
Addresses (HBAs) [RFC5535], DHCPv6 [RFC3315], or static,
semantically opaque addresses [RFC7217] SHOULD be used by default.
In situations where the devices address embedded in the IID are
required to support deployment constraints, 6LN MAY form a 64-bit
IID by utilizing the MAC-48 device address or DECT device addresses.
The non-link-local addresses 6LN generates MUST be registered with
6LBR as described in Section 3.2.2.</t>
<t>The means for a 6LBR to obtain an IPv6 prefix for numbering the
DECT ULE network is out of scope of this document, but can be, for
example, accomplished via DHCPv6 Prefix Delegation [RFC3633] or by
using Unique Local IPv6 Unicast Addresses (ULA) [RFC4193]. Due to
the link model of the DECT ULE the 6LBR MUST set the "on-link" flag
(L) to zero in the Prefix Information Option [RFC4861]. This will
cause 6LNs to always send packets to the 6LBR, including the case
when the destination is another 6LN using the same prefix.</t>
<t>A 6LN MUST NOT register more than one non-link-local addres on
the same prefix.</t>
<t/>
</section>
<section title="Neighbor discovery">
<t>'Neighbor Discovery Optimization for IPv6 over Low-Power Wireless
Personal Area Networks (6LoWPANs)' [RFC6775] describes the neighbor
discovery approach as adapted for use in several 6LoWPAN topologies,
including the mesh topology. As DECT ULE is considered not to
support mesh networks, hence only those aspects that apply to a star
topology are considered.</t>
<t>The following aspects of the Neighbor Discovery optimizations
[RFC6775] are applicable to DECT ULE 6LNs:</t>
<t>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].</t>
<t>2. A DECT ULE 6LN MUST NOT register its link-local address. A
DECT ULE 6LN MUST register its non-link-local addresses with the
6LBR by sending a Neighbor Solicitation (NS) message with the
Address 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.</t>
</section>
<section title="Unicast and Multicast address mapping">
<t>The DECT MAC layer broadcast service is considered inadequate for
IP multicast.</t>
<t>Hence traffic is always unicast between two DECT ULE nodes. Even
in the case where a 6LBR is attached to multiple 6LNs, the 6LBR
cannot do a multicast to all the connected 6LNs. If the 6LBR needs
to send a multicast packet to all its 6LNs, it has to replicate the
packet and unicast it on each link. However, this may not be
energy-efficient and particular care should be taken if the FP is
battery-powered. To further conserve power, the 6LBR MUST keep track
of multicast listeners at DECT-ULE link level granularity and it
MUST NOT forward multicast packets to 6LNs that have not registered
for multicast groups the packets belong to. In the opposite
direction, a 6LN can only transmit data to or through the 6LBR.
Hence, when a 6LN needs to transmit an IPv6 multicast packet, the
6LN will unicast the corresponding DECT ULE packet to the 6LBR. The
6LBR will then forward the multicast packet to other 6LNs.</t>
</section>
<section title="Header Compression">
<t>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.</t>
<section title="Link-local Header Compression">
<t>In a link-local communication terminated at 6LN and 6LBR, both
the IPv6 source and destination addresses MUST be elided, since
the used IIDs map uniquely into the DECT link end point addresses.
A 6LN or 6LBR that receives a PDU containing an IPv6 packet can
infer the corresponding IPv6 source address. For the type of
communication considered in this paragraph, the following settings
MUST be used in the IPv6 compressed header: CID=0, SAC=0, SAM=11,
DAC=0, DAM=11.</t>
</section>
<section title="Non-link-local Header Compression">
<t>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.</t>
<t>When a 6LN transmits an IPv6 packet to a destination using
global Unicast IPv6 addresses, if a context is defined for the
prefix of the 6LNs global IPv6 address, the 6LN MUST indicate this
context in the corresponding source fields of the compressed IPv6
header as per Section 3.1 of [RFC6282], and MUST elide the IPv6
source address. For this, the 6LN MUST use the following settings
in the IPv6 compressed header: CID=1, SAC=1, SAM=11. In this case,
the 6LBR can infer the elided IPv6 source address since 1) the
6LBR has previously assigned the prefix to the 6LNs; and 2) the
6LBR maintains a Neighbor Cache that relates the Device Address
and the IID of the corresponding PP. If a context is defined for
the IPv6 destination address, the 6LN MUST also indicate this
context in the corresponding destination fields of the compressed
IPv6 header, and MUST elide the prefix of the destination IPv6
address. For this, the 6LN MUST set the DAM field of the
compressed IPv6 header as CID=1, DAC=1 and DAM=01 or DAM=11. Note
that when a context is defined for the IPv6 destination address,
the 6LBR can infer the elided destination prefix by using the
context.</t>
<t>When a 6LBR receives a IPv6 packet having a global Unicast IPv6
address, and the destination of the packet is a 6LN, if a context
is defined for the prefix of the 6LN's global IPv6 address, the
6LBR MUST indicate this context in the corresponding destination
fields of the compressed IPv6 header, and MUST elide the IPv6
destination address of the packet before forwarding it to the 6LN.
For this, the 6LBR MUST set the DAM field of the IPv6 compressed
header as DAM=11. CID and DAC MUST be set to CID=1 and DAC=1. If a
context is defined for the prefix of the IPv6 source address, the
6LBR MUST indicate this context in the source fields of the
compressed IPv6 header, and MUST elide that prefix as well. For
this, the 6LBR MUST set the SAM field of the IPv6 compressed
header as CID=1, SAC=1 and SAM=01 or SAM=11.</t>
<t/>
</section>
</section>
</section>
<section title="Subnets and Internet connectivity scenarios">
<t>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.</t>
<t>Other scenarios can be imagined where a PP is acting as 6LBR and
providing Internet connectivity for the FP. How the FP could then
further provide Internet connectivity to other PP, possibly connected
to the FP, is out of the scope of this document.</t>
<figure>
<artwork>
6LN
\ ____________
\ / \
6LN ---- 6LBR --- | Internet |
/ \____________/
/
6LN
<-- DECT ULE -->
Figure 5: DECT ULE network connected to the Internet
</artwork>
</figure>
<t>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.</t>
<figure>
<artwork>
6LN 6LN
\ /
\ /
6LN --- 6LBR --- 6LN
/ \
/ \
6LN 6LN
<------ DECT ULE ----->
Figure 6: Isolated DECT ULE network
</artwork>
</figure>
<t>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.</t>
</section>
</section>
<section anchor="IANA" title="IANA Considerations">
<t>There are no IANA considerations related to this document.</t>
</section>
<section anchor="Security" title="Security Considerations">
<t>The secure transmission of speech over DECT will be based on the
DSAA2 and DSC/DSC2 specification developed by ETSI TC DECT and the ETSI
SAGE Security expert group.</t>
<t>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.</t>
<t>The DECT ULE pairing procedure generates a master authentication key
(UAK). During location registration procedure or when the permanent
virtual circuit are established, the session security keys are
generated. Session security keys may be renewed regularly. The generated
security keys (UAK and session security keys) are individual for each
FP-PP binding, hence all PP in a system have different security keys.
DECT ULE PPs do not use any shared encryption key.</t>
<t>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].</t>
</section>
<section anchor="ETSI" title="ETSI Considerations">
<t>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.</t>
<t>The ETSI DECT ULE Application Protocol Identifier is specified to
0x06 for 6LoWPAN [TS102.939-1].</t>
</section>
<section anchor="Acknowledgements" title="Acknowledgements">
<t>We are grateful to the members of the IETF 6lo working group; this
document borrows liberally from their work.</t>
<t>Ralph Droms and Samita Chakrabarti have provided valuable feedback
for this draft.</t>
</section>
</middle>
<back>
<references title="Normative References">
&RFC2119;
&RFC2464;
&RFC3633;
&RFC4193;
&RFC4861;
&RFC4862;
&RFC4941;
&RFC4944;
&RFC6282;
&RFC4291;
&RFC6775;
&RFC7136;
<reference anchor="EN300.175-part1-7"
target="https://www.etsi.org/deliver/etsi_en/300100_300199/30017501/02.06.01_60/en_30017501v020601p.pdf">
<front>
<title>Digital Enhanced Cordless Telecommunications (DECT); Common
Interface (CI);</title>
<author>
<organization abbrev="ETSI">ETSI</organization>
</author>
<date month="March" year="2015"/>
</front>
</reference>
<reference anchor="TS102.939-1"
target="https://www.etsi.org/deliver/etsi_ts/102900_102999/10293901/01.02.01_60/ts_10293901v010201p.pdf">
<front>
<title>Digital Enhanced Cordless Telecommunications (DECT); Ultra
Low Energy (ULE); Machine to Machine Communications; Part 1: Home
Automation Network (phase 1)</title>
<author>
<organization abbrev="ETSI">ETSI</organization>
</author>
<date month="March" year="2015"/>
</front>
</reference>
<reference anchor="TS102.939-2"
target="https://www.etsi.org/deliver/etsi_ts/102900_102999/10293902/01.01.01_60/ts_10293902v010101p.pdf">
<front>
<title>Digital Enhanced Cordless Telecommunications (DECT); Ultra
Low Energy (ULE); Machine to Machine Communications; Part 2: Home
Automation Network (phase 2)</title>
<author>
<organization abbrev="ETSI">ETSI</organization>
</author>
<date month="March" year="2015"/>
</front>
</reference>
</references>
<references title="Informative References">
<reference anchor="CAT-iq"
target="http://www.dect.org/userfiles/Public/DF_CAT-iq%20Certification%20Overview.pdf">
<front>
<title>Cordless Advanced Technology - internet and quality</title>
<author>
<organization abbrev="DECTforum">DECT Forum</organization>
</author>
<date month="January" year="2016"/>
</front>
</reference>
&RFC3315;
&RFC3610;
&RFC3972;
&RFC5535;
&RFC7217;
&RFC7668;
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-22 03:17:55 |