< draft-ietf-6lo-dect-ule-03.txt   draft-ietf-6lo-dect-ule-04.txt >
6Lo Working Group P. Mariager 6Lo Working Group P. Mariager
Internet-Draft J. Petersen, Ed. Internet-Draft J. Petersen, Ed.
Intended status: Standards Track RTX A/S Intended status: Standards Track RTX A/S
Expires: March 18, 2016 Z. Shelby Expires: August 29, 2016 Z. Shelby
ARM ARM
M. Van de Logt M. Van de Logt
Gigaset Communications GmbH Gigaset Communications GmbH
D. Barthel D. Barthel
Orange Labs Orange Labs
September 15, 2015 February 26, 2016
Transmission of IPv6 Packets over DECT Ultra Low Energy Transmission of IPv6 Packets over DECT Ultra Low Energy
draft-ietf-6lo-dect-ule-03 draft-ietf-6lo-dect-ule-04
Abstract Abstract
DECT Ultra Low Energy is a low power air interface technology that is DECT Ultra Low Energy is a low power air interface technology that is
defined by the DECT Forum and specified by ETSI. defined by the DECT Forum and specified by ETSI.
The DECT air interface technology has been used world-wide in The DECT air interface technology has been used world-wide in
communication devices for more than 20 years, primarily carrying communication devices for more than 20 years, primarily carrying
voice for cordless telephony but has also been deployed for data voice for cordless telephony but has also been deployed for data
centric services. centric services.
skipping to change at page 2, line 10 skipping to change at page 2, line 10
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on March 18, 2016. This Internet-Draft will expire on August 29, 2016.
Copyright Notice Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the Copyright (c) 2016 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
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 . . . . . . . . . . . . . . . . . . . . . . . 4
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 . . . . . . . . . . . . . . . 5
2.2. Link layer roles and topology . . . . . . . . . . . . . . 6 2.2. Link layer roles and topology . . . . . . . . . . . . . . 6
2.3. Addressing Model . . . . . . . . . . . . . . . . . . . . 6 2.3. Addressing Model . . . . . . . . . . . . . . . . . . . . 7
2.4. MTU Considerations . . . . . . . . . . . . . . . . . . . 7 2.4. MTU Considerations . . . . . . . . . . . . . . . . . . . 7
2.5. Additional Considerations . . . . . . . . . . . . . . . . 7 2.5. Additional Considerations . . . . . . . . . . . . . . . . 8
3. Specification of IPv6 over DECT ULE . . . . . . . . . . . . . 7 3. Specification of IPv6 over DECT ULE . . . . . . . . . . . . . 8
3.1. Protocol stack . . . . . . . . . . . . . . . . . . . . . 8 3.1. Protocol stack . . . . . . . . . . . . . . . . . . . . . 9
3.2. Link model . . . . . . . . . . . . . . . . . . . . . . . 8 3.2. Link model . . . . . . . . . . . . . . . . . . . . . . . 9
3.3. Subnets and Internet connectivity scenarios . . . . . . . 13 3.3. Subnets and Internet connectivity scenarios . . . . . . . 13
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
5. Security Considerations . . . . . . . . . . . . . . . . . . . 14 5. Security Considerations . . . . . . . . . . . . . . . . . . . 15
6. ETSI Considerations . . . . . . . . . . . . . . . . . . . . . 15 6. ETSI Considerations . . . . . . . . . . . . . . . . . . . . . 15
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 15 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 16
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 16
8.1. Normative References . . . . . . . . . . . . . . . . . . 15 8.1. Normative References . . . . . . . . . . . . . . . . . . 16
8.2. Informative References . . . . . . . . . . . . . . . . . 17 8.2. Informative References . . . . . . . . . . . . . . . . . 18
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18
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 at the expense of data throughput. DECT ULE devices with consumption at the expense of data throughput. DECT (Digital
requirements on power consumption will operate on special power Enhanced Cordless Telecommunications) is a standard series
optimized silicon, but can connect to a DECT Gateway supporting [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 traditional DECT / CAT-iq for cordless telephony and data as well as
the ULE extensions. DECT terminology operates with two major role the ULE extensions. DECT terminology operates with two major role
definitions: The Portable Part (PP) is the power constrained device, definitions: The Portable Part (PP) is the power constrained device,
while the Fixed Part (FP) is the Gateway or base station. This FP 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 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 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 bytes) at periodic intervals through the FP, but is able to wake up
upon an external event (burglar) and communicate with the FP. upon an external event (burglar) and communicate with the FP.
Another example incorporating both DECT ULE as well as traditional Another example incorporating both DECT ULE as well as traditional
CAT-iq telephony is an elderly pendant (broche) which can transmit CAT-iq telephony is an elderly pendant (broche) which can transmit
skipping to change at page 3, line 35 skipping to change at page 3, line 40
establish a voice connection through the pendant to an alarm service. establish a voice connection through the pendant to an alarm service.
It is expected that DECT ULE will be integrated into many residential It is expected that DECT ULE will be integrated into many residential
gateways, as many of these already implements DECT CAT-iq for gateways, as many of these already implements DECT CAT-iq for
cordless telephony. DECT ULE can be added as a software option 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 FP. It is desirable to consider IPv6 for DECT ULE devices due to
the large address space and well-known infrastructure. This document the large address space and well-known infrastructure. This document
describes how IPv6 is used on DECT ULE links to optimize power while describes how IPv6 is used on DECT ULE links to optimize power while
maintaining the many benefits of IPv6 transmission. [RFC4944], maintaining the many benefits of IPv6 transmission. [RFC4944],
[RFC6282] and [RFC6775] specify the transmission of IPv6 over IEEE [RFC6282] and [RFC6775] specify the transmission of IPv6 over IEEE
802.15.4. DECT ULE has many characteristics similar to those of IEEE 802.15.4. DECT ULE has many characteristics similar to those of IEEE
802.15.4, but also differences. Many of the mechanisms defined for 802.15.4, but also differences. A subset of mechanisms defined for
transmission of IPv6 over IEEE 802.15.4 can be applied to the transmission of IPv6 over IEEE 802.15.4 can be applied to the
transmission of IPv6 on DECT ULE links. transmission of IPv6 on DECT ULE links.
This document specifies how to map IPv6 over DECT ULE inspired by This document specifies how to map IPv6 over DECT ULE inspired by
[RFC4944], [RFC6282], [RFC6775] and [I-D.ietf-6lo-btle]. [RFC4944], [RFC6282], [RFC6775] and [RFC7668].
1.1. Requirements Notation 1.1. Requirements Notation
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
1.2. Terms Used 1.2. Terms Used
PP: DECT Portable Part, typically the sensor node 6CO: 6LoWPAN Context Option [RFC6775]
6LBR: DECT Fixed Part having a role as defined in [RFC6775]
FP: DECT Fixed Part, the gateway 6LN: DECT Portable part having a role as defined in [RFC6775]
LLME: Lower Layer Management Entity 6LoWPAN: IPv6 over Low-Power Wireless Personal Area Network
AES128: Advanced Encryption Standard with key size of 128 bits
RFPI: Radio Fixed Part Identity API: Application Programming Interface
ARO: Address Registration Option [RFC6775]
IPEI: International Portable Equipment Identity CAT-iq: Corless Advanced Technologi - internet and quality
CID: Context Identifier [RFC6775]
TPUI: Temporary Portable User Identity DAC: Destination Address Compression
DAM: Destination Address Mode
PMID: Portable MAC Identity DHCPv6: Dynamic Host Configuration Protocol for IPv6 [RFC3315]
DLC: Data Link Control
PVC: Permanent Virtual Circuit DSAA2: DECT Standard Authentication Algorithm #2
DSC: DECT Standard Cipher
6LN: DECT Portable part having a role as defined in [RFC6775] DSC2: DECT Standard Cipher #2
FDMA: Frequency Division Multiplex
6LBR: DECT Fixed Part having a role as defined in [RFC6775] 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]
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 51 skipping to change at page 5, line 28
The DECT ULE device can switch to the ULE mode of operation, The DECT ULE device can switch to the ULE mode of operation,
utilizing the new ULE MAC layer features. The DECT ULE Data Link utilizing the new ULE MAC layer features. The DECT ULE Data Link
Control (DLC) provides multiplexing as well as segmentation and re- Control (DLC) provides multiplexing as well as segmentation and re-
assembly for larger packets from layers above. The DECT ULE layer assembly for larger packets from layers above. The DECT ULE layer
also implements per-message authentication and encryption. The DLC also implements per-message authentication and encryption. The DLC
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, this document is not considering usage of the
been standardized for higher layers. This document is not DECT ULE MAC layer broadcast service.
considering usage of this DECT ULE MAC broadcast service in current
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 on power down modes employed in the PP, latency PP side. Depending on power down modes employed in the PP, latency
may occur when initiating sessions from FP side. MAC layer may occur when initiating sessions from FP side. MAC layer
communication can take place using either connection oriented packet communication can take place using either connection oriented packet
transfer with low overhead for short sessions or take place using transfer with low overhead for short sessions or take place using
connection oriented bearers including media reservation. The MAC connection oriented bearers including media reservation. The MAC
layer autonomously selects the radio spectrum positions that are layer autonomously selects the radio spectrum positions that are
available within the band and can rearrange these to avoid available within the band and can rearrange these to avoid
interference. The MAC layer has built-in retransmission procedures interference. The MAC layer has built-in retransmission procedures
skipping to change at page 5, line 30 skipping to change at page 6, line 6
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 defines 6LoWPAN as one of the possible established. This draft defines 6LoWPAN as one of the possible
protocols to negotiate. protocols to negotiate.
+----------------------------------------+ +----------------------------------------+
| Applications | | Application Layers |
+----------------------------------------+ +----------------------------------------+
| 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)| |
+--------------------+-------------------+ +--------------------+-------------------+
| DECT DLC | DECT ULE DLC | | DECT DLC | DECT ULE DLC |
+--------------------+-------------------+ +--------------------+-------------------+
| MAC Layer | | MAC Layer |
+--------------------+-------------------+ +--------------------+-------------------+
| Physical Layer | | PHY Layer |
+--------------------+-------------------+ +--------------------+-------------------+
(C-plane) (U-plane) (C-plane) (U-plane)
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- Figure 1 above shows the DECT ULE Stack divided into the Control-
data (U-plane) parts shown to the left and to the right in figure 1, plane and User-data path, to left and to the right, respectively.
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.
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 6LBR and a 6LN, respectively. primary scenario FP and PP will act as 6LBR and a 6LN, respectively.
This document does only address this primary scenario. This document does only address this primary scenario.
In DECT ULE, at link layer the communication only takes place between 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 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 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. 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
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.
DECT ULE repeaters are not considered in this document. DECT ULE repeaters are not considered in this document.
2.3. Addressing Model 2.3. Addressing Model
Each DECT PP is assigned an IPEI during manufacturing. This identity Each DECT PP is assigned an IPEI during manufacturing. This identity
has the size of 40 bits and is DECT globally unique for the PP and 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 can be used to constitute the MAC address. However, it cannot be
used to derive a globally unique IID. used to derive a globally unique IID.
When bound to a FP, a PP is assigned a 20 bit TPUI which is unique 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 within the FP. This TPUI is used for addressing (layer 2) in
messages between FP and PP. messages between FP and PP.
Each DECT FP is assigned a RFPI during manufacturing. This identity 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 has the size of 40 bits and is globally unique for a FP and can be
used to constitute the MAC address. However, it cannot be used to used to constitute the MAC address used to derive the IID for link-
derive a globally unique IID. local address. However, it cannot be used to derive a globally
unique IID.
Alternatively each DECT PP and DECT FP can be assigned a unique Optionally each DECT PP and DECT FP can be assigned a unique (IEEE)
(IEEE) MAC-48 address additionally to the DECT identities to be used MAC-48 address additionally to the DECT identities to be used by the
by the 6LoWPAN. With such an approach, the FP and PP have to 6LoWPAN. During the address registration of non-link-local addresses
implement a mapping between used MAC-48 addresses and DECT as specified by this document, the FP and PP can use such MAC-48 to
identities. construct the IID.
2.4. MTU Considerations 2.4. MTU Considerations
Generally the DECT ULE FP and PP may be generating data that fits Idially the DECT ULE FP and PP may generate data that fits into a
into a single MAC Layer packet (38 octets) for periodically single MAC Layer packets (38 octets) for periodically transferred
transferred information, depending on application. IP data packets information, depending on application. However, IP packets may be
may be much larger and hence MTU size should be the size of the IP much larger. The DECT ULE DLC procedures supports segmentation and
data packet. The DECT ULE DLC procedures supports segmentation and reassembly of any MTU size below 65536 octets, but the default MTU
reassembly of any MTU size below 65536 octets, but most size defined in DECT ULE [TS102.939-1] is 500 octets. In order to
implementations do only support smaller values. The default MTU size support complete IP packets, the DLC layer of DECT ULE SHALL per this
in DECT ULE is 500 octets, but it SHALL be configured to fit the specification be configured with a MTU size that fits the
requirements from IPv6 data packets, hence [RFC4944] fragmentation/ requirements from IPv6 data packets, hence [RFC4944] fragmentation/
reassembly is not required. reassembly is not required.
It is expected that the LOWPAN_IPHC packet will fulfill all the It is expected that the LOWPAN_IPHC packet will fulfill all the
requirements for header compression without spending unnecessary requirements for header compression without spending unnecessary
overhead for mesh addressing. overhead for mesh addressing.
It is important to realize that the usage of larger packets will be It is important to realize that the usage of larger packets will be
at the expense of battery life, as a large packet inside the DECT ULE at the expense of battery life, as a large packet inside the DECT ULE
stack will be fragmented into several or many MAC layer packets, each stack will be fragmented into several or many MAC layer packets, each
skipping to change at page 8, line 8 skipping to change at page 8, line 48
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.
A significant difference between IEEE 802.15.4 and DECT ULE is that As consequence of DECT ULE in it's primary configuration does not
the former supports both star and mesh topology (and requires a support the formation of multihop networks at the link layer, the
routing protocol), whereas DECT ULE in it's primary configuration mesh header defined in [RFC4944] for mesh under routing MUST NOT be
does not support the formation of multihop networks at the link used. In addition, a DECT ULE PP node MUST NOT play the role of a
layer. In consequence, the mesh header defined in [RFC4944] for mesh 6LoWPAN Router (6LR).
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).
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 and the MTU size to 1280 Application Protocol Identifier to 0x06 and the MTU size to 1280
skipping to change at page 8, line 48 skipping to change at page 9, line 39
| 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 fragmentation and reassembly layer 2. The DECT ULE implements already fragmentation and
functionality and [RFC4944] fragmentation and reassembly function reassembly functionality, hence [RFC4944] fragmentation and
MUST NOT be used. Since IPv6 requires MTU size of at least 1280 reassembly function MUST NOT be used. The DECT ULE DLC link (PVC)
octets, the DECT ULE connection (PVC) MUST be configured with MUST be configured with a minimum MTU size of at least 1280 octers in
equivalent MTU size. order to meet the size requirements of IPv6.
Per this specification, the IPv6 header compression format specified Per this specification, the IPv6 header compression format specified
in [RFC6282] MUST be used. The IPv6 payload length can be derived in [RFC6282] MUST be used. The IPv6 payload length can be derived
from the ULE DLC packet length and the possibly elided IPv6 address 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 can be reconstructed from the link-layer address, used at the time of
DECT ULE connection establishment, from the ULE MAC packet address, DECT ULE connection establishment, from the ULE MAC packet address,
compression context if any, and from address registration information compression context if any, and from address registration information
(see Section 3.2.2). (see Section 3.2.2).
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 cannot talk to one another with link-local addresses. another and cannot talk to one another with link-local addresses.
However, the FP acts as a 6LBR for communication between the PPs. 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 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 be considered up and IPv6 address configuration and transmission
can begin. The FP ensures address collisions do not 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 At network interface initialization, both 6LN and 6LBR SHALL generate
[RFC4862]. Following the guidance of [RFC7136], a 64-bit Interface and assign to the DECT ULE network interface IPv6 link-local
identifier (IID) for a DECT ULE interface MAY be formed by utilizing addresses [RFC4862] based on the DECT device addresses (see
a MAC-48 device address as defined in [RFC2464] "IPv6 over Ethernet" Section 2.3) that were used for establishing the underlying DECT ULE
specification. connection.
Alternatively, the DECT device addresses IPEI, RFPI or TPUI, MAY be The DECT device addresses IPEI and RFPI MUST be used to derive the
used instead to derive the IID. These DECT devices addresses IPv6 link-local 64 bit Interface Identifiers (IID) for 6LN and 6LBR,
consisting of 40, 40 and 20 bits respectively, MUST be expanded with respectively.
leading bits to form a 48 bit address. Least significant bit of this
address is the last bit in network order. The expanded leading bits
are all zeros except for 7th bit indicating not global unique. First
bit is set to a one for addresses derived from the RFPI and 2nd bit
is set to one when the address is derived from the PMID. For example
from IPEI=01.23.45.67.89 is derived MAC address equal
02:01:23:45:67:89 and from PMID=0.01.23 is derived MAC address equal
42:00:00:00:01:23.
As defined in [RFC4291], the IPv6 link-local address for a DECT ULE The rule for deriving IID from DECT device addresses is as follows:
node is formed by appending the IID, to the prefix FE80::/64, as The DECT device addresses that are consisting of 40 bits each, MUST
shown in Figure 4. 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.
As defined in [RFC4291], the IPv6 link-local address is formed by
appending the IID, to the prefix FE80::/64, as shown in Figure 4.
10 bits 54 bits 64 bits 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. A 6LN MUST join the all-nodes multicast address.
After link-local address configuration, 6LN sends Router Solicitation After link-local address configuration, 6LN sends Router Solicitation
messages as described in [RFC4861] Section 6.3.7. messages as described in [RFC4861] Section 6.3.7.
For non-link-local addresses a 64-bit IID MAY be formed by utilizing For non-link-local addresses, 6LNs SHOULD NOT be configured to use
a MAC-48 device address. For non-link-local addresses, 6LNs SHOULD IIDs derived from a MAC-48 device address or DECT device addresses.
NOT be configured to use IIDs derived from a MAC-48 device address. Alternative schemes such as Cryptographically Generated Addresses
By default a 6LN SHOULD use a randomly generated IID (see (CGAs) [RFC3972], privacy extensions [RFC4941], Hash-Based Addresses
Section 3.2.2), for example, as discussed in [I-D.ietf-6man-default- (HBAs) [RFC5535], DHCPv6 [RFC3315], or static, semantically opaque
iids], or use alternative schemes such as Cryptographically Generated addresses [RFC7217] SHOULD be used by default. In situations where
Addresses (CGA) [RFC3972], privacy extensions [RFC4941], Hash-Based the devices address embedded in the IID are required to support
Addresses (HBA, [RFC5535]), DHCPv6 [RFC3315], or static, semantically deployment constraints, 6LN MAY form a 64-bit IID by utilizing the
opaque addresses [RFC7217]. In situations where the devices address MAC-48 device address or DECT device addresses. The non-link-local
embedded in the IID are required to support deployment constraints, addresses 6LN generates MUST be registered with 6LBR as described in
6LN MAY form a 64-bit IID by utilizing the MAC-48 device address. Section 3.2.2.
The non-link-local addresses 6LN generates MUST be registered with
6LBR as described in Section 3.2.2.
The means for a 6LBR to obtain an IPv6 prefix for numbering the DECT 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.
A 6LN MUST NOT register more than one non-link-local addres on the
same prefix.
3.2.2. Neighbor discovery 3.2.2. Neighbor discovery
'Neighbor Discovery Optimization for IPv6 over Low-Power Wireless 'Neighbor Discovery Optimization for IPv6 over Low-Power Wireless
Personal Area Networks (6LoWPANs)' [RFC6775] describes the neighbor Personal Area Networks (6LoWPANs)' [RFC6775] describes the neighbor
discovery approach as adapted for use in several 6LoWPAN topologies, discovery approach as adapted for use in several 6LoWPAN topologies,
including the mesh topology. As DECT ULE is considered not to including the mesh topology. As DECT ULE 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
skipping to change at page 11, line 43 skipping to change at page 12, line 35
needs to transmit an IPv6 multicast packet, the 6LN will unicast the needs to transmit an IPv6 multicast packet, the 6LN will unicast the
corresponding DECT ULE packet to the 6LBR. The 6LBR will then corresponding DECT ULE packet to the 6LBR. The 6LBR will then
forward the multicast packet to other 6LNs. forward the multicast packet to other 6LNs.
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,
and ARO can be exploited in order to provide a mechanism for addess ARO and 6CO can be exploited in order to provide a mechanism for
compression. The following text describes the principles of IPv6 address compression. The following text describes the principles of
address compression on top of DECT ULE. IPv6 address compression on top of DECT ULE.
3.2.4.1. Link-local Header Compression 3.2.4.1. Link-local Header Compression
In a link-local communication terminated at 6LN and 6LBR, both the In a link-local communication terminated at 6LN and 6LBR, both the
IPv6 source and destination addresses MUST be elided, since the node IPv6 source and destination addresses MUST be elided, since the used
knows that the packet is destined for it even if the packet does not IIDs map uniquely into the DECT link end point addresses. A 6LN or
have destination IPv6 address. A node SHALL learn the IID of the 6LBR that receives a PDU containing an IPv6 packet can infer the
other endpoint of each DECT ULE connection it participates in. By corresponding IPv6 source address. For the type of communication
exploiting this information, a node that receives a PDU containing an considered in this paragraph, the following settings MUST be used in
IPv6 packet can infer the corresponding IPv6 source address. A node the IPv6 compressed header: CID=0, SAC=0, SAM=11, DAC=0, DAM=11.
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.
3.2.4.2. Non-link-local Header Compression 3.2.4.2. Non-link-local Header Compression
To enable efficient header compression, the 6LBR MUST include 6LoWPAN To enable efficient header compression, the 6LBR MUST include 6LoWPAN
Context Option (6CO) [RFC6775] for all prefixes the 6LBR advertises Context Option (6CO) [RFC6775] for all prefixes the 6LBR advertises
in Router Advertisements for use in stateless address in Router Advertisements for use in stateless address
autoconfiguration. autoconfiguration.
When a 6LN transmits an IPv6 packet to a destination using global 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 Unicast IPv6 addresses, if a context is defined for the prefix of the
skipping to change at page 13, line 15 skipping to change at page 14, line 5
SAM=11. SAM=11.
3.3. Subnets and Internet connectivity scenarios 3.3. Subnets and 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. In this scenario, the DECT ULE 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 network is deployed as one subnet, using one /64 IPv6 prefix. The
6LBR is acting as router and forwarding packets between 6LNs and to 6LBR is acting as router and forwarding packets between 6LNs and to
and from Internet. and from Internet.
A degenerate scenario can be imagined where a PP is acting as 6LBR Other scenarios can be imagined where a PP is acting as 6LBR and
and providing Internet connectivity for the FP. How the FP could providing Internet connectivity for the FP. How the FP could then
then further provide Internet connectivity to other PP, possibly further provide Internet connectivity to other PP, possibly connected
connected to the FP, is out of the scope of this document. to the FP, is out of the scope of this document.
6LN 6LN
\ ____________ \ ____________
\ / \ \ / \
6LN ---- 6LBR --- | Internet | 6LN ---- 6LBR --- | Internet |
/ \____________/ / \____________/
/ /
6LN 6LN
<-- DECT ULE --> <-- DECT ULE -->
skipping to change at page 14, line 29 skipping to change at page 15, line 12
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 developed by the DF Security group / ETSI TC DECT DSAA2 and DSC/DSC2 specification developed by ETSI TC DECT and the
and the ETSI SAGE Security expert group. 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). During location registration procedure or when the permanent
permanent virtual circuit are established, the session security keys virtual circuit are established, the session security keys are
are generated. Session security keys may be renewed regularly. The 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 From privacy point of view, the IPv6 link-local address configuration
implementations the choice to support, for example, [I-D.ietf-6man- described in Section 3.2.1 only reveals information about the 6LN to
default-iids], [RFC3315], [RFC3972], [RFC4941], [RFC5535] or the 6LBR that the 6LBR already knows from the link-layer connection.
[RFC7217] for non-link-local addresses. For non-link-local IPv6 addresses, by default a 6LN SHOULD use a
randomly generated IID, for example, as discussed in [I-D.ietf-6man-
default- iids], or use alternative schemes such as Cryptographically
Generated Addresses (CGA) [RFC3972], privacy extensions [RFC4941],
Hash-Based Addresses (HBA, [RFC5535]), or static, semantically opaque
addresses [RFC7217].
6. ETSI Considerations 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 is standardized by ETSI. a common protocol identifier for 6LoWPAN is standardized by ETSI.
The ETSI DECT ULE Application Protocol Identifier is specified to The ETSI DECT ULE Application Protocol Identifier is specified to
0x06 for 6LoWPAN [TS102.939-1]. 0x06 for 6LoWPAN [TS102.939-1].
7. Acknowledgements 7. Acknowledgements
We are grateful to the members of the IETF 6lo working group; this We are grateful to the members of the IETF 6lo working group; this
document borrows liberally from their work. document borrows liberally from their work.
Ralph Droms has provided valuable feedback for this draft. Ralph Droms and Samita Chakrabarti have provided valuable feedback
for this draft.
8. References 8. References
8.1. Normative References 8.1. Normative References
[EN300.175-part1-7] [EN300.175-part1-7]
ETSI, "Digital Enhanced Cordless Telecommunications ETSI, "Digital Enhanced Cordless Telecommunications
(DECT); Common Interface (CI);", March 2015. (DECT); Common Interface (CI);", March 2015,
<https://www.etsi.org/deliver/
etsi_en/300100_300199/30017501/02.06.01_60/
en_30017501v020601p.pdf>.
[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, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>. <http://www.rfc-editor.org/info/rfc2119>.
[RFC2464] Crawford, M., "Transmission of IPv6 Packets over Ethernet [RFC2464] Crawford, M., "Transmission of IPv6 Packets over Ethernet
Networks", RFC 2464, DOI 10.17487/RFC2464, December 1998, Networks", RFC 2464, DOI 10.17487/RFC2464, December 1998,
<http://www.rfc-editor.org/info/rfc2464>. <http://www.rfc-editor.org/info/rfc2464>.
skipping to change at page 16, line 48 skipping to change at page 17, line 39
<http://www.rfc-editor.org/info/rfc6775>. <http://www.rfc-editor.org/info/rfc6775>.
[RFC7136] Carpenter, B. and S. Jiang, "Significance of IPv6 [RFC7136] Carpenter, B. and S. Jiang, "Significance of IPv6
Interface Identifiers", RFC 7136, DOI 10.17487/RFC7136, Interface Identifiers", RFC 7136, DOI 10.17487/RFC7136,
February 2014, <http://www.rfc-editor.org/info/rfc7136>. February 2014, <http://www.rfc-editor.org/info/rfc7136>.
[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)", March 2015. 1)", March 2015, <https://www.etsi.org/deliver/
etsi_ts/102900_102999/10293901/01.02.01_60/
ts_10293901v010201p.pdf>.
[TS102.939-2] [TS102.939-2]
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 2: Home Automation Network (phase Communications; Part 2: Home Automation Network (phase
2)", March 2015. 2)", March 2015, <https://www.etsi.org/deliver/
etsi_ts/102900_102999/10293902/01.01.01_60/
ts_10293902v010101p.pdf>.
8.2. Informative References 8.2. Informative References
[I-D.ietf-6lo-btle] [CAT-iq] DECT Forum, "Cordless Advanced Technology - internet and
Nieminen, J., Savolainen, T., Isomaki, M., Patil, B., quality", January 2016,
Shelby, Z., and C. Gomez, "IPv6 over BLUETOOTH(R) Low <http://www.dect.org/userfiles/Public/
Energy", draft-ietf-6lo-btle-17 (work in progress), August DF_CAT-iq%20Certification%20Overview.pdf>.
2015.
[I-D.ietf-6man-default-iids]
Gont, F., Cooper, A., Thaler, D., and S. LIU,
"Recommendation on Stable IPv6 Interface Identifiers",
draft-ietf-6man-default-iids-07 (work in progress), August
2015.
[RFC3315] Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins, [RFC3315] Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins,
C., and M. Carney, "Dynamic Host Configuration Protocol C., and M. Carney, "Dynamic Host Configuration Protocol
for IPv6 (DHCPv6)", RFC 3315, DOI 10.17487/RFC3315, July for IPv6 (DHCPv6)", RFC 3315, DOI 10.17487/RFC3315, July
2003, <http://www.rfc-editor.org/info/rfc3315>. 2003, <http://www.rfc-editor.org/info/rfc3315>.
[RFC3610] Whiting, D., Housley, R., and N. Ferguson, "Counter with [RFC3610] Whiting, D., Housley, R., and N. Ferguson, "Counter with
CBC-MAC (CCM)", RFC 3610, DOI 10.17487/RFC3610, September CBC-MAC (CCM)", RFC 3610, DOI 10.17487/RFC3610, September
2003, <http://www.rfc-editor.org/info/rfc3610>. 2003, <http://www.rfc-editor.org/info/rfc3610>.
skipping to change at page 17, line 48 skipping to change at page 18, line 35
[RFC5535] Bagnulo, M., "Hash-Based Addresses (HBA)", RFC 5535, [RFC5535] Bagnulo, M., "Hash-Based Addresses (HBA)", RFC 5535,
DOI 10.17487/RFC5535, June 2009, DOI 10.17487/RFC5535, June 2009,
<http://www.rfc-editor.org/info/rfc5535>. <http://www.rfc-editor.org/info/rfc5535>.
[RFC7217] Gont, F., "A Method for Generating Semantically Opaque [RFC7217] Gont, F., "A Method for Generating Semantically Opaque
Interface Identifiers with IPv6 Stateless Address Interface Identifiers with IPv6 Stateless Address
Autoconfiguration (SLAAC)", RFC 7217, Autoconfiguration (SLAAC)", RFC 7217,
DOI 10.17487/RFC7217, April 2014, DOI 10.17487/RFC7217, April 2014,
<http://www.rfc-editor.org/info/rfc7217>. <http://www.rfc-editor.org/info/rfc7217>.
[RFC7668] Nieminen, J., Savolainen, T., Isomaki, M., Patil, B.,
Shelby, Z., and C. Gomez, "IPv6 over BLUETOOTH(R) Low
Energy", RFC 7668, DOI 10.17487/RFC7668, October 2015,
<http://www.rfc-editor.org/info/rfc7668>.
Authors' Addresses Authors' Addresses
Peter B. Mariager 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 (editor) 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 ARM
150 Rose Orchard 150 Rose Orchard
San Jose, CA 95134 San Jose, CA 95134
USA USA
Email: zach.shelby@arm.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
 End of changes. 46 change blocks. 
156 lines changed or deleted 201 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/