6Lo Working Group P. Mariager, Ed.
Internet-Draft J. Petersen
Intended status: Standards Track RTX A/S
Expires: November 8, 2014 Z. Shelby
Sensinode
M. Van de Logt
Gigaset Communications GmbH
D. Barthel
Orange Labs
May 7, 2014
Transmission of IPv6 Packets over DECT Ultra Low Energy
draft-mariager-6lo-v6over-dect-ule-03
Abstract
DECT Ultra Low Energy is a low power air interface technology that is
defined by the DECT Forum and specified by ETSI.
The DECT air interface technology has been used world-wide in
communication devices for more than 15 years, primarily carrying
voice for cordless telephony but has also been deployed for data
centric services.
The DECT Ultra Low Energy is a recent addition to the DECT interface
primarily intended for low-bandwidth, low-power applications such as
sensor devices, smart meters, home automation etc. As the DECT Ultra
Low Energy interface inherits many of the capabilities from DECT, it
benefits from long range, interference free operation, world wide
reserved frequency band, low silicon prices and maturity. There is
an added value in the ability to communicate with IPv6 over DECT ULE
such as for Internet of Things applications.
This document describes how IPv6 is transported over DECT ULE using
6LoWPAN techniques.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Mariager, et al. Expires November 8, 2014 [Page 1]
Internet-Draft IPv6 over DECT ULE May 2014
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on November 8, 2014.
Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Requirements Notation . . . . . . . . . . . . . . . . . . 3
1.2. Terms Used . . . . . . . . . . . . . . . . . . . . . . . 3
2. DECT Ultra Low Energy . . . . . . . . . . . . . . . . . . . . 4
2.1. The DECT ULE Protocol Stack . . . . . . . . . . . . . . . 4
2.2. Link layer roles and topology . . . . . . . . . . . . . . 5
2.3. Addressing Model . . . . . . . . . . . . . . . . . . . . 6
2.4. MTU Considerations . . . . . . . . . . . . . . . . . . . 7
2.5. Additional Considerations . . . . . . . . . . . . . . . . 7
3. Specification of IPv6 over DECT ULE . . . . . . . . . . . . . 7
3.1. Protocol stack . . . . . . . . . . . . . . . . . . . . . 8
3.2. Link model . . . . . . . . . . . . . . . . . . . . . . . 8
3.3. Internet connectivity scenarios . . . . . . . . . . . . . 12
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
5. Security Considerations . . . . . . . . . . . . . . . . . . . 13
6. ETSI Considerations . . . . . . . . . . . . . . . . . . . . . 13
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13
8. Normative References . . . . . . . . . . . . . . . . . . . . 13
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15
Mariager, et al. Expires November 8, 2014 [Page 2]
Internet-Draft IPv6 over DECT ULE May 2014
1. Introduction
DECT Ultra Low Energy (DECT ULE or just ULE) is an air interface
technology building on the key fundamentals of traditional DECT /
CAT-iq but with specific changes to significantly reduce the power
consumption on the expense of data throughput. DECT ULE devices with
requirements to power consumption will operate on special power
optimized silicon, but can connect to a DECT Gateway supporting
traditional DECT / CAT-iq for cordless telephony and data as well as
the ULE extensions. DECT terminology operates with two major role
definitions: The Portable Part (PP) is the power constrained device,
while the Fixed Part (FP) is the Gateway or base station. This FP
may be connected to the Internet. An example of a use case for DECT
ULE is a home security sensor transmitting small amounts of data (few
bytes) at periodic intervals through the FP, but is able to wake up
upon an external event (burglar) and communicate with the FP.
Another example incorporating both DECT ULE as well as traditional
CAT-iq telephony is an elderly pendant (broche) which can transmit
periodic status messages to a care provider using very little
battery, but in the event of urgency, the elderly person can
establish a voice connection through the pendant to an alarm service.
It is expected that DECT ULE will be integrated into many residential
gateways, as many of these already implements DECT CAT-iq for
cordless telephony. DECT ULE can be added as a software option for
the FP. It is desirable to consider IPv6 for DECT ULE devices due to
the large address space and well-known infrastructure. This document
describes how IPv6 is used on DECT ULE links to optimize power while
maintaining the many benefits of IPv6 transmission. [RFC4944]
specifies the transmission of IPv6 over IEEE 802.15.4. DECT ULE has
in many ways similar characteristics of IEEE 802.15.4, but also
differences. Many of the mechanisms defined in [RFC4944] can be
applied to the transmission of IPv6 on DECT ULE links.
This document specifies how to map IPv6 over DECT ULE inspired by
[RFC4944].
1.1. Requirements Notation
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
1.2. Terms Used
PP: DECT Portable Part, typically the sensor node
FP: DECT Fixed Part, the gateway
Mariager, et al. Expires November 8, 2014 [Page 3]
Internet-Draft IPv6 over DECT ULE May 2014
LLME: Lower Layer Management Entity
NWK: Network
PVC: Permanent Virtual Circuit
FAR: Fragmentation and Reassembly
2. DECT Ultra Low Energy
DECT ULE is a low power air interface technology that is designed to
support both circuit switched for service, such as voice
communication, and for packet mode data services at modest data rate.
This draft is only addressing the packet mode data service of DECT
ULE.
2.1. The DECT ULE Protocol Stack
The DECT ULE protocol stack consists of the PHY layer operating at
frequencies in the 1880 - 1920 MHz frequency band depending on the
region and uses a symbol rate of 1.152 Mbps. Radio bearers are
allocated by use of FDMA/TDMA/TDD technics.
In its generic network topology, DECT is defined as a cellular
network technology. However, the most common configuration is a star
network with a single FP defining the network with a number of PP
attached. The MAC layer supports both traditional DECT as this is
used for services like discovery, pairing, security features etc.
All these features have been reused from DECT.
The DECT ULE device can switch to the ULE mode of operation,
utilizing the new ULE MAC layer features. The DECT ULE Data Link
Control (DLC) provides multiplexing as well as segmentation and re-
assembly for larger packets from layers above. The DECT ULE layer
also implements per-message authentication and encryption. The DLC
layer ensures packet integrity and preserves packet order, but
delivery is based on best effort.
The current DECT ULE MAC layer standard supports low bandwidth data
broadcast. However the usage of this broadcast service has not yet
been standardized for higher layers. This document is not
considering usage of this DECT ULE MAC broadcast service in current
version.
In general, communication sessions can be initiated from both FP and
PP side. Depending of power down modes employed in the PP, latency
may occur when initiating sessions from FP side. MAC layer
communication can either take place using connection oriented packet
Mariager, et al. Expires November 8, 2014 [Page 4]
Internet-Draft IPv6 over DECT ULE May 2014
transfer with low overhead for short sessions or take place using
connection oriented bearers including media reservation. The MAC
layer autonomously selects the radio spectrum positions that are
available within the band and can rearrange these to avoid
interference. The MAC layer has built-in retransmission procedures
in order to improve transmission reliability.
The DECT ULE device will typically incorporate an Application
Programmers Interface (API) as well as common elements known as
Generic Access Profile (GAP) for enrolling into the network. The
DECT ULE stack establishes a permanent virtual circuit (PVC) for the
application layers and provides support for a range of different
application protocols. The used application protocol is negotiated
between the PP and FP when the PVC communication service is
established. This draft proposes to define 6LoWPAN as one of the
possible protocols to negotiate.
+----------------------------------------+
| Applications |
+----------------------------------------+
| Generic Access | ULE Profile |
| Profile | |
+----------------------------------------+
| DECT/Service API | ULE Data API |
+--------------------+-------------------+
| LLME | NWK (MM,CC)| |
+--------------------+-------------------+
| DECT DLC | DECT ULE DLC |
+--------------------+-------------------+
| MAC Layer |
+--------------------+-------------------+
| Physical Layer |
+--------------------+-------------------+
(C-plane) (U-plane)
Figure 1: DECT ULE Protocol Stack
The DECT ULE stack can be divided into control (C-plane) and user-
data (U-plane) parts shown to the left and to the right in figure 1,
respectively.
2.2. Link layer roles and topology
A FP is assumed to be less constrained than a PP. Hence, in the
primary scenario FP and PP will act as 6LoWPAN Border Router (6LBR)
Mariager, et al. Expires November 8, 2014 [Page 5]
Internet-Draft IPv6 over DECT ULE May 2014
and a 6LoWPAN Node (6LN), respectively. This document does only
address this primary scenario.
In DECT ULE, communication only takes place between a FP and a PP. A
FP is able to handle multiple simultaneous connections with a number
of PP. Hence, in a DECT ULE network using IPv6, a radio hop is
equivalent to an IPv6 link and vice versa.
[DECT ULE PP]-----\ /-----[DECT ULE PP]
\ /
[DECT ULE PP]-------+[DECT ULE FP]+-------[DECT ULE PP]
/ \
[DECT ULE PP]-----/ \-----[DECT ULE PP]
Figure 2: DECT ULE star topology
DECT ULE repeaters are not considered in this proposal.
2.3. Addressing Model
Each DECT PP is assigned an <IPEI> (International Portable Equipment
Identity) during manufacturing. This identity has the size of 40
bits and is DECT globally unique for the PP and can be used to
constitute the MAC address. However, it can not be used to derive a
globally unique IID.
When bound to a FP, a PP is assigned a 20 bit TPUI (Temporary
Portable User Identity) which is unique within the FP. This TPUI is
used for addressing (layer 2) in messages between FP and PP.
Each DECT FP is assigned a <RFPI> (Radio Fixed Part Identity) during
manufacturing. This identity has the size of 40 bits and is globally
unique for a FP and can be used to constitute the MAC address.
However, it can not be used to derive a globally unique IID.
Alternatively each DECT PP and DECT FP can be assigned a unique
(IEEE) MAC-48 address additionally to the DECT identities to be used
by the 6LoWPAN. With such an approach, the FP and PP have to
implement a mapping between used MAC-48 addresses and DECT
identities.
Mariager, et al. Expires November 8, 2014 [Page 6]
Internet-Draft IPv6 over DECT ULE May 2014
2.4. MTU Considerations
Generally the DECT ULE FP and PP may be generating data that fits
into one MAC Layer packet (38 bytes) for periodically transferred
information, depending on application. IP data packets may be much
larger and hence MTU size should be the size of the IP data packet.
The DECT ULE DLC procedures supports segmentation and reassembly of
any MTU size below 65536 bytes, but most implementations do only
support smaller values.
It is expected that the LOWPAN_IPHC packet will fulfill all the
requirements for header compression without spending unnecessary
overhead for mesh addressing.
It is important to realize that the support of larger packets will be
on the expense of battery life, as a large packet will be fragmented
into several or many MAC layer packets, each consuming power to
transmit / receive.
2.5. Additional Considerations
The DECT ULE standard allows PP to be registered (bind) to multiple
FP and roaming between these FP. This draft does not consider the
scenarios of PP roaming between multiple FP. The use of repeater
functionality is also not considered in this draft.
3. Specification of IPv6 over DECT ULE
DECT ULE technology sets strict requirements for low power
consumption and thus limits the allowed protocol overhead. 6LoWPAN
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.
The ULE 6LoWPAN adaptation layer can run directly on this U-plane DLC
layer. Figure 3 illustrates IPv6 over DECT ULE stack.
A significant difference between IEEE 802.15.4 and DECT ULE is that
the former supports both star and mesh topology (and requires a
routing protocol), whereas DECT ULE in it's primary configuration
does not support the formation of multihop networks at the link
layer. In consequence, the mesh header defined in [RFC4944] for mesh
under routing MUST NOT be used in DECT ULE networks. In addition, a
DECT ULE PP node MUST NOT play the role of a 6LoWPAN Router (6LR).
Mariager, et al. Expires November 8, 2014 [Page 7]
Internet-Draft IPv6 over DECT ULE May 2014
3.1. Protocol stack
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 (reserved for 6LoWPAN and has
to be standardized by ETSI) 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.
+-------------------+
| UDP/TCP/other |
+-------------------+
| IPv6 |
+-------------------+
|6LoWPAN adapted to |
| DECT ULE |
+-------------------+
| DECT ULE DLC |
+-------------------+
| DECT ULE MAC |
+-------------------+
| DECT ULE PHY |
+-------------------+
Figure 3: IPv6 over DECT ULE Stack
3.2. Link model
The general model is that IPv6 is layer 3 and DECT ULE MAC+DLC is
layer 2. The DECT ULE implements FAR functionality and [RFC4944]
MUST NOT be used. Since IPv6 requires MTU size of at least 1280
octets, the DECT ULE connection (PVC) must be configured with
configured with equivalent MTU size.
This specification also assumes the IPv6 header compression format
specified in [RFC6282]. It is also assumed that the IPv6 payload
length can be inferred from the ULE DLC packet length and the IID
value inferred from the link-layer address.
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 also cannot talk to one another with link-local
Mariager, et al. Expires November 8, 2014 [Page 8]
Internet-Draft IPv6 over DECT ULE May 2014
addresses. 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.
3.2.1. Stateless address autoconfiguration
A DECT ULE 6LN performs stateless address autoconfiguration as per
[RFC4862]. A 64-bit Interface identifier (IID) for a DECT ULE
interface MAY be formed by utilizing a MAC-48 device address as
defined in [RFC2464] "IPv6 over Ethernet" specification.
Alternatively, the DECT device addresses IPEI, RFPI or TPUI, MAY be
used instead to derive the IID. In the case of randomly generated
IID or use of IID derived from DECT devices addresses, the "Universal
/Local" bit MUST be set to 0. Only if a global unique MAC-48 is used
the "Universal/Local" bit can be set to 1.
As defined in [RFC4291], the IPv6 link-local address for a DECT ULE
node is formed by appending the IID, to the prefix FE80::/64, as
shown in Figure 4.
10 bits 54 bits 64 bits
+----------+-----------------+----------------------+
|1111111010| zeros | Interface Identifier |
+----------+-----------------+----------------------+
Figure 4: IPv6 link-local address in DECT ULE
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.
3.2.2. Neighbor discovery
'Neighbor Discovery Optimization for IPv6 over Low-Power Wireless
Personal Area Networks (6LoWPANs)' [RFC6775] describes the neighbor
discovery approach as adapted for use in several 6LoWPAN topologies,
including the mesh topology. As DECT ULE is considered not to
support mesh networks, hence only those aspects that apply to a star
topology are considered.
Mariager, et al. Expires November 8, 2014 [Page 9]
Internet-Draft IPv6 over DECT ULE May 2014
The following aspects of the Neighbor Discovery optimizations
[RFC6775] are applicable to DECT ULE 6LNs:
1. A DECT ULE 6LN MUST register its address with the 6LBR by sending
a Neighbor Solicitation (NS) message with the ARO option and process
the Neighbor Advertisement (NA) accordingly. The NS with the ARO
option SHOULD be sent irrespective of whether the IID is derived from
a unique MAC-48 bit device address, 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
5.3 and 5.4 of the [RFC6775].
3.2.3. Unicast and Multicast address mapping
The DECT MAC layer broadcast service is considered inadequate for IP
multicast.
Hence traffic is always unicast between two DECT ULE nodes. Even in
the case where a FP is attached to multiple PPs, the FP cannot do a
multicast to all the connected PPs. If the FP needs to send a
multicast packet to all its PPs, it has to replicate the packet and
unicast it on each link. However, this may not be energy-efficient
and particular care must be taken if the FP is battery-powered. In
the opposite direction, a PP can only transmit data to a single
destination (i.e. the FP). Hence, when a PP needs to transmit an
IPv6 multicast packet, the PP will unicast the corresponding DECT ULE
packet to the FP. As described in the linkmodel section, the FP will
not forward link-local multicast messages to other PPs connected to
the FP.
3.2.4. Header Compression
Header compression as defined in [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
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.
Mariager, et al. Expires November 8, 2014 [Page 10]
Internet-Draft IPv6 over DECT ULE May 2014
In a link-local communication, both the IPv6 source and destination
addresses MUST be elided [RFC6282], since the node knows that the
packet is destined for it even if the packet does not have
destination IPv6 address. A node SHALL learn the IID of the other
endpoint of each DECT ULE connection it participates in. By
exploiting this information, a node that receives a PDU containing an
IPv6 packet can infer the corresponding IPv6 source address. A node
MUST maintain a Neighbor Cache, in which the entries include both the
IID of the neighbor and the Device Address that identifies the
neighbor. For the type of communication considered in this
paragraph, the following settings MUST be used in the IPv6 compressed
header: CID=0, SAC=0, SAM=11, DAC=0, DAM=11.
When a 6LN transmits an IPv6 packet to a remote destination using
global Unicast IPv6 addresses, if a context is defined for the prefix
of the 6LNs global IPv6 address, the 6LN MUST indicate this context
in the corresponding source fields of the compressed IPv6 header as
per Section 3.1 of [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 DAM=01 (if the context
covers a 64-bit prefix) or as DAM=11 (if the context covers a full,
128-bit address). CID and DAC MUST be set to CID=1 and DAC=1. Note
that when a context is defined for the IPv6 destination address, the
6LBR can infer the elided destination prefix by using the context.
When a 6LBR receives an IPv6 packet sent by a remote node outside the
DECT ULE network, and the destination of the packet is a 6LN, if a
context is defined for the prefix of the 6LN's global IPv6 address,
the 6LBR MUST indicate this context in the corresponding destination
fields of the compressed IPv6 header, and MUST elide the IPv6
destination address of the packet before forwarding it to the 6LN.
For this, the 6LBR MUST set the DAM field of the IPv6 compressed
header as DAM=11. CID and DAC MUST be set to CID=1 and DAC=1. If a
context is defined for the prefix of the IPv6 source address, the
6LBR MUST indicate this context in the source fields of the
compressed IPv6 header, and MUST elide that prefix as well. For
this, the 6LBR MUST set the SAM field of the IPv6 compressed header
as SAM=01 (if the context covers a 64-bit prefix) or SAM=11 (if the
context covers a full, 128-bit address). CID and SAC MUST be set to
CID=1 and SAC=1.
Mariager, et al. Expires November 8, 2014 [Page 11]
Internet-Draft IPv6 over DECT ULE May 2014
3.3. Internet connectivity scenarios
In a typical scenario, the DECT ULE network is connected to the
Internet as shown in the Figure 5.
A degenerate scenario can be imagined where a PP is acting as 6LBR
and providing Internet connectivity for the FP. How the FP could
then further provide Internet connectivity to other PP, possibly
connected to the FP, is out of the scope of this document.
6LN
\ ____________
\ / \
6LN ---- 6LBR --- | Internet |
/ \____________/
/
6LN
<-- DECT ULE -->
Figure 5: DECT ULE network connected to the Internet
In some scenarios, the DECT ULE network may transiently or
permanently be an isolated network as shown in the Figure 6.
6LN 6LN
\ /
\ /
6LN --- 6LBR --- 6LN
/ \
/ \
6LN 6LN
<------ DECT ULE ----->
Figure 6: Isolated DECT ULE network
In the isolated network scenario, communications between 6LN and 6LBR
can use IPv6 link-local methodology, but for communications between
different PP, the FP has to act as 6LBR, number the network with ULA
prefix [RFC4193], and route packets between PP.
Mariager, et al. Expires November 8, 2014 [Page 12]
Internet-Draft IPv6 over DECT ULE May 2014
4. IANA Considerations
There are no IANA considerations related to this document.
5. Security Considerations
The secure transmission of speech over DECT will be based on the
DSAA2 and DSC2 work being developed by the DF Security group / ETSI
TC DECT and the ETSI SAGE Security expert group.
DECT ULE communications are secured at the link-layer (DLC) by
encryption and per-message authentication through CCM mode (Counter
with CBC-MAC) similar to [RFC3610]. The underlying algorithm for
providing encryption and authentication is AES128.
The DECT ULE pairing procedure generates a master authentication key
(UAK) and 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.
6. ETSI Considerations
ETSI is standardizing a list of known application layer protocols
that can use the DECT ULE permanent virtual circuit packet data
service. Each protocol is identified by a unique known identifier,
which is exchanged in the service-change procedure as defined in
[TS102.939-1]. The IPv6/6LoWPAN as described in this document is
considered as an application layer protocol on top of DECT ULE. In
order to provide interoperability between 6LoWPAN / DECT ULE devices
a common protocol identifier for 6LoWPAN has to be standardized by
ETSI.
It is proposed to use ETSI DECT ULE Application Protocol Identifier
equal 0x06 for 6LoWPAN.
7. Acknowledgements
8. Normative References
[EN300.175-part1-7]
ETSI, "Digital Enhanced Cordless Telecommunications
(DECT); Common Interface (CI);", August 2013.
Mariager, et al. Expires November 8, 2014 [Page 13]
Internet-Draft IPv6 over DECT ULE May 2014
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2464] Crawford, M., "Transmission of IPv6 Packets over Ethernet
Networks", RFC 2464, December 1998.
[RFC3610] Whiting, D., Housley, R., and N. Ferguson, "Counter with
CBC-MAC (CCM)", RFC 3610, September 2003.
[RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic
Host Configuration Protocol (DHCP) version 6", RFC 3633,
December 2003.
[RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast
Addresses", RFC 4193, October 2005.
[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing
Architecture", RFC 4291, February 2006.
[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
"Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,
September 2007.
[RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless
Address Autoconfiguration", RFC 4862, September 2007.
[RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy
Extensions for Stateless Address Autoconfiguration in
IPv6", RFC 4941, September 2007.
[RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler,
"Transmission of IPv6 Packets over IEEE 802.15.4
Networks", RFC 4944, September 2007.
[RFC6282] Hui, J. and P. Thubert, "Compression Format for IPv6
Datagrams over IEEE 802.15.4-Based Networks", RFC 6282,
September 2011.
[RFC6775] Shelby, Z., Chakrabarti, S., Nordmark, E., and C. Bormann,
"Neighbor Discovery Optimization for IPv6 over Low-Power
Wireless Personal Area Networks (6LoWPANs)", RFC 6775,
November 2012.
[TS102.939-1]
ETSI, "Digital Enhanced Cordless Telecommunications
(DECT); Ultra Low Energy (ULE); Machine to Machine
Communications; Part 1: Home Automation Network (phase
1)", April 2013.
Mariager, et al. Expires November 8, 2014 [Page 14]
Internet-Draft IPv6 over DECT ULE May 2014
Authors' Addresses
Peter B. Mariager (editor)
RTX A/S
Stroemmen 6
DK-9400 Noerresundby
Denmark
Email: pm@rtx.dk
Jens Toftgaard Petersen
RTX A/S
Stroemmen 6
DK-9400 Noerresundby
Denmark
Email: jtp@rtx.dk
Zach Shelby
Sensinode
Hallituskatu 13-17D
FI-90100 Oulu
Finland
Email: zach.shelby@sensinode.com
Marco van de Logt
Gigaset Communications GmbH
Frankenstrasse 2
D-46395 Bocholt
Germany
Email: marco.van-de-logt@gigaset.com
Dominique Barthel
Orange Labs
Email: dominique.barthel@orange.com
Mariager, et al. Expires November 8, 2014 [Page 15]