< draft-ietf-6lo-dect-ule-05.txt   draft-ietf-6lo-dect-ule-06.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: November 17, 2016 Z. Shelby Expires: April 6, 2017 Z. Shelby
ARM ARM
M. Van de Logt M. Van de Logt
Gigaset Communications GmbH Gigaset Communications GmbH
D. Barthel D. Barthel
Orange Labs Orange Labs
May 16, 2016 October 3, 2016
Transmission of IPv6 Packets over DECT Ultra Low Energy Transmission of IPv6 Packets over DECT Ultra Low Energy
draft-ietf-6lo-dect-ule-05 draft-ietf-6lo-dect-ule-06
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 November 17, 2016. This Internet-Draft will expire on April 6, 2017.
Copyright Notice Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the Copyright (c) 2016 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 32 skipping to change at page 2, line 32
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 . . . . . . . . . . . . . . . . . . . . . . . 4 1.2. Terms Used . . . . . . . . . . . . . . . . . . . . . . . 4
2. DECT Ultra Low Energy . . . . . . . . . . . . . . . . . . . . 4 2. DECT Ultra Low Energy . . . . . . . . . . . . . . . . . . . . 5
2.1. The DECT ULE Protocol Stack . . . . . . . . . . . . . . . 5 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 . . . . . . . . . . . . . . . . . . . . 7 2.3. Addressing Model . . . . . . . . . . . . . . . . . . . . 7
2.4. MTU Considerations . . . . . . . . . . . . . . . . . . . 7 2.4. MTU Considerations . . . . . . . . . . . . . . . . . . . 8
2.5. Additional Considerations . . . . . . . . . . . . . . . . 8 2.5. Additional Considerations . . . . . . . . . . . . . . . . 8
3. Specification of IPv6 over DECT ULE . . . . . . . . . . . . . 8 3. Specification of IPv6 over DECT ULE . . . . . . . . . . . . . 8
3.1. Protocol Stack . . . . . . . . . . . . . . . . . . . . . 9 3.1. Protocol Stack . . . . . . . . . . . . . . . . . . . . . 9
3.2. Link Model . . . . . . . . . . . . . . . . . . . . . . . 9 3.2. Link Model . . . . . . . . . . . . . . . . . . . . . . . 10
3.3. Subnets and Internet Connectivity Scenarios . . . . . . . 13 3.3. Subnets and Internet Connectivity Scenarios . . . . . . . 14
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
5. Security Considerations . . . . . . . . . . . . . . . . . . . 15 5. Security Considerations . . . . . . . . . . . . . . . . . . . 16
6. ETSI Considerations . . . . . . . . . . . . . . . . . . . . . 15 6. ETSI Considerations . . . . . . . . . . . . . . . . . . . . . 17
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 16 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 17
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 17
8.1. Normative References . . . . . . . . . . . . . . . . . . 16 8.1. Normative References . . . . . . . . . . . . . . . . . . 17
8.2. Informative References . . . . . . . . . . . . . . . . . 17 8.2. Informative References . . . . . . . . . . . . . . . . . 19
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20
1. Introduction 1. Introduction
DECT Ultra Low Energy (DECT ULE or just ULE) is an air interface DECT (Digital Enhanced Cordless Telecommunications) is a standard
technology building on the key fundamentals of traditional DECT / series [EN300.175-part1-7] specified by ETSI and CAT-iq (Cordless
CAT-iq but with specific changes to significantly reduce the power Advanced Technology - internet and quality) is a set of product
consumption at the expense of data throughput. DECT (Digital certification and interoperability profiles [CAT-iq] defined by DECT
Enhanced Cordless Telecommunications) is a standard series Forum. DECT Ultra Low Energy (DECT ULE or just ULE) is an air
[EN300.175-part1-7] specified by ETSI and CAT-iq (Cordless Advanced interface technology building on the key fundamentals of traditional
Technology - internet and quality) is a set of product certication DECT / CAT-iq but with specific changes to significantly reduce the
and interoperability profiles [CAT-iq] defined by DECT Forum. DECT power consumption at the expense of data throughput. DECT ULE
ULE devices with requirements on power consumption as specified by devices with requirements on power consumption as specified by ETSI
ETSI in [TS102.939-1] and [TS102.939-2], will operate on special in [TS102.939-1] and [TS102.939-2], will operate on special power
power optimized silicon, but can connect to a DECT Gateway supporting optimized silicon, but can connect to a DECT Gateway supporting
traditional DECT / CAT-iq for cordless telephony and data as well as traditional DECT / CAT-iq for cordless telephony and data as well as
the ULE extensions. DECT terminology operates with two major role the ULE extensions. DECT terminology 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 4, line 7 skipping to change at page 4, line 7
[RFC4944], [RFC6282], [RFC6775] and [RFC7668]. [RFC4944], [RFC6282], [RFC6775] and [RFC7668].
1.1. Requirements Notation 1.1. Requirements Notation
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
1.2. Terms Used 1.2. Terms Used
6CO: 6LoWPAN Context Option [RFC6775] 6CO: 6LoWPAN Context Option [RFC6775]
6LBR: DECT Fixed Part having a role as defined in [RFC6775] 6BBR: 6loWPAN Backbone Router
6LN: DECT Portable part having a role as defined in [RFC6775] 6LBR: 6LoWPAN Border Router as defined in [RFC6775]. The DECT Fixed
6LoWPAN: IPv6 over Low-Power Wireless Personal Area Network Part is having this role
AES128: Advanced Encryption Standard with key size of 128 bits 6LN: 6LoWPAN Node as defined in [RFC6775]. The DECT Portable part
API: Application Programming Interface is having this role
ARO: Address Registration Option [RFC6775] 6LoWPAN: IPv6 over Low-Power Wireless Personal Area Network
CAT-iq: Cordless Advanced Technology - internet and quality AES128: Advanced Encryption Standard with key size of 128 bits
CID: Context Identifier [RFC6775] API: Application Programming Interface
DAC: Destination Address Compression ARO: Address Registration Option [RFC6775]
DAM: Destination Address Mode CAT-iq: Cordless Advanced Technology - internet and quality
DHCPv6: Dynamic Host Configuration Protocol for IPv6 [RFC3315] CID: Context Identifier [RFC6775]
DLC: Data Link Control DAC: Destination Address Compression
DSAA2: DECT Standard Authentication Algorithm #2 DAM: Destination Address Mode
DSC: DECT Standard Cipher DHCPv6: Dynamic Host Configuration Protocol for IPv6 [RFC3315]
DSC2: DECT Standard Cipher #2 DLC: Data Link Control
FDMA: Frequency Division Multiplex DSAA2: DECT Standard Authentication Algorithm #2
FP: DECT Fixed Part, the gateway DSC: DECT Standard Cipher
GAP: Generic Access Profile DSC2: DECT Standard Cipher #2
IID: Interface Identifier FDMA: Frequency Division Multiplex
IPEI: International Portable Equipment Identity; (DECT identity) FP: DECT Fixed Part, the gateway
MAC-48: 48 bit global unique MAC address managed by IEEE GAP: Generic Access Profile
MAC: Media Access Control IID: Interface Identifier
MTU: Maximum Transmission Unit IPEI: International Portable Equipment Identity; (DECT identity)
ND: Neighbor Discovery [RFC4861] [RFC6775] MAC-48: 48 bit global unique MAC address managed by IEEE
PDU: Protocol Data Unit MAC: Media Access Control
PHY: Physical Layer MTU: Maximum Transmission Unit
PMID: Portable MAC Identity; (DECT identity) NBMA: Non-broadcast multi-access
PP: DECT Portable Part, typically the sensor node (6LN) ND: Neighbor Discovery [RFC4861] [RFC6775]
PVC: Permanent Virtual Circuit PDU: Protocol Data Unit
RFPI: Radio Fixed Part Identity; (DECT identity) PHY: Physical Layer
SAC: Source Address Compression PMID: Portable MAC Identity; (DECT identity)
SAM: Source Address Mode PP: DECT Portable Part, typically the sensor node (6LN)
TDD: Time Division Duplex PVC: Permanent Virtual Circuit
TDMA: Time Division Multiplex RFPI: Radio Fixed Part Identity; (DECT identity)
TPUI: Temporary Portable User Identity; (DECT identity) SAC: Source Address Compression
UAK: User Authentication Key, DECT master security key SAM: Source Address Mode
ULA: Unique Local Address [RFC4193] 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
The DECT ULE protocol stack consists of the PHY layer operating at The DECT ULE protocol stack consists of the PHY layer operating at
frequencies in the 1880 - 1920 MHz frequency band depending on the frequencies in the 1880 - 1920 MHz frequency band depending on the
region and uses a symbol rate of 1.152 Mbps. Radio bearers are region and uses a symbol rate of 1.152 Mbps. Radio bearers are
allocated by use of FDMA/TDMA/TDD technics. allocated by use of FDMA/TDMA/TDD techniques.
In its generic network topology, DECT is defined as a cellular In its generic network topology, DECT is defined as a cellular
network technology. However, the most common configuration is a star network technology. However, the most common configuration is a star
network with a single FP defining the network with a number of PP network with a single FP defining the network with a number of PP
attached. The MAC layer supports both traditional DECT as this is attached. The MAC layer supports both traditional DECT circuit mode
used for services like discovery, pairing, security features etc. operation as this is used for services like discovery, pairing,
All these features have been reused from DECT. security features etc, and it supports new ULE packet mode operation.
The circuit mode features have been reused from DECT.
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, this document is not considering usage of the broadcast. However, this document is not considering usage of the
DECT ULE MAC layer broadcast service. DECT ULE MAC layer broadcast service for IPv6 over DECT ULE.
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 6, line 38 skipping to change at page 6, line 45
Media Access Control Layer, (DLC) Data Link Control Layer, (NWK) Media Access Control Layer, (DLC) Data Link Control Layer, (NWK)
Network Layer with subcomponents: (LLME) Lower Layer Management Network Layer with subcomponents: (LLME) Lower Layer Management
Entity, (MM) Mobility Management and (CC) Call Control. Above there Entity, (MM) Mobility Management and (CC) Call Control. Above there
are the typically (API) Application Programmers Interface and are the typically (API) Application Programmers Interface and
application profile specific layers. application profile specific layers.
2.2. Link Layer Roles and Topology 2.2. Link Layer Roles and Topology
A FP is assumed to be less constrained than a PP. Hence, in the A FP is assumed to be less constrained than a PP. Hence, in the
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 only addresses this primary scenario and all other
scenarios are out of scope.
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 (see
Section 3.3).
[DECT ULE PP]-----\ /-----[DECT ULE PP] [DECT ULE PP]-----\ /-----[DECT ULE PP]
\ / \ /
[DECT ULE PP]-------+[DECT ULE FP]+-------[DECT ULE PP] [DECT ULE PP]-------+[DECT ULE FP]+-------[DECT ULE PP]
/ \ / \
[DECT ULE PP]-----/ \-----[DECT ULE PP] [DECT ULE PP]-----/ \-----[DECT ULE PP]
Figure 2: DECT ULE star topology Figure 2: DECT ULE star topology
A significant difference between IEEE 802.15.4 and DECT ULE is that A significant difference between IEEE 802.15.4 and DECT ULE is that
the former supports both star and mesh topology (and requires a the former supports both star and mesh topology (and requires a
routing protocol), whereas DECT ULE in it's primary configuration routing protocol), whereas DECT ULE in it's primary configuration
does not support the formation of multihop networks at the link does not support the formation of multihop networks at the link
layer. In consequence, the mesh header defined in [RFC4944] for mesh layer. In consequence, the mesh header defined in [RFC4944] for mesh
under routing are not used in DECT ULE networks. under routing are not used in DECT ULE networks.
DECT ULE repeaters are not considered in this document. DECT ULE repeaters are considered to operate in the DECT protocol
domain and are outside the scope of this document.
2.3. Addressing Model 2.3. Addressing Model
Each DECT PP is assigned an IPEI during manufacturing. This identity Each DECT PP is assigned an IPEI during manufacturing. This identity
has the size of 40 bits and is DECT globally unique for the PP and has the size of 40 bits and is globally unique within DECT addressing
can be used to constitute the MAC address. However, it cannot be space and can be used to constitute the MAC address used to derive
used to derive a globally unique IID. the IID for link-local address. However, it cannot be used to derive
a globally unique IID.
When bound to a FP, a PP is assigned a 20 bit TPUI which is unique During a DECT location registration procedure, the FP assigns a 20
within the FP. This TPUI is used for addressing (layer 2) in bit TPUI to a PP. The FP creates a unique mapping between the
messages between FP and PP. assigned TPUI and the IPEI of each PP. This TPUI is used for
addressing (layer 2) in messages between FP and PP. Although the
TPUI is temporary by definition, the same value is usually repeatedly
assigned to any given PP, hence it seems not suitable for
construction of IID, see [I-D.ietf-6lo-privacy-considerations].
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 within DECT addressing
used to constitute the MAC address used to derive the IID for link- space and can be used to constitute the MAC address used to derive
local address. However, it cannot be used to derive a globally the IID for link-local address. However, it cannot be used to derive
unique IID. a globally unique IID.
Optionally each DECT PP and DECT FP can be assigned a unique (IEEE) 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 MAC-48 address additionally to the DECT identities to be used by the
6LoWPAN. During the address registration of non-link-local addresses 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 as specified by this document, the FP and PP can use such MAC-48 to
construct the IID. construct the IID. However, as these addresses are considered as
being permanent, such scheme is not recommended as per [I-D.ietf-6lo-
privacy-considerations].
2.4. MTU Considerations 2.4. MTU Considerations
Ideally the DECT ULE FP and PP may generate data that fits into a Ideally the DECT ULE FP and PP may generate data that fits into a
single MAC Layer packets (38 octets) for periodically transferred single MAC Layer packets (38 octets) for periodically transferred
information, depending on application. However, IP packets may be information, depending on application. However, IP packets may be
much larger. The DECT ULE DLC procedures supports segmentation and much larger. The DECT ULE DLC procedures natively support
reassembly of any MTU size below 65536 octets, but the default MTU segmentation and reassembly and provide any MTU size below 65536
size defined in DECT ULE [TS102.939-1] is 500 octets. In order to octets. The default MTU size defined in DECT ULE [TS102.939-1] is
support complete IP packets, the DLC layer of DECT ULE SHALL per this 500 octets. In order to support complete IPv6 packets, the DLC layer
specification be configured with a MTU size that fits the of DECT ULE shall per this specification be configured with a MTU
requirements from IPv6 data packets, hence [RFC4944] fragmentation/ size of 1280 octets, hence [RFC4944] fragmentation/reassembly is not
reassembly is not required. required.
It is expected that the LOWPAN_IPHC packet will fulfil all the It is expected that the LOWPAN_IPHC packet will fulfil 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
consuming power to transmit / receive. consuming power to transmit / receive. The increased MTU size does
not change the MAC layer packet and PDU size.
2.5. Additional Considerations 2.5. Additional Considerations
The DECT ULE standard allows PP to be registered (bind) to multiple The DECT ULE standard allows PP to be DECT-registered (bind) to
FP and roaming between these FP. This draft does not consider the multiple FP and roaming between them. These FP and their 6LBR
scenarios of PP roaming between multiple FP. The use of repeater functionalities can either operate individual or connected through a
functionality is also not considered in this draft. Backbone Router as per [I-D.ietf-6lo-backbone-router].
3. Specification of IPv6 over DECT ULE 3. Specification of IPv6 over DECT ULE
Before any IP-layer communications can take place over DECT ULE, DECT Before any IP-layer communications can take place over DECT ULE, DECT
ULE enabled nodes such as 6LNs and 6LBRs have to find each other and ULE enabled nodes such as 6LNs and 6LBRs have to find each other and
establish a suitable link-layer connection. The obtain-access-rights establish a suitable link-layer connection. The obtain-access-rights
registration and location registration procedures are documented by registration and location registration procedures are documented by
ETSI in the specifications [EN300.175-part1-7], [TS102.939-1] and ETSI in the specifications [EN300.175-part1-7], [TS102.939-1] and
[TS102.939-2]. [TS102.939-2].
skipping to change at page 9, line 9 skipping to change at page 9, line 24
layer. Figure 3 illustrates IPv6 over DECT ULE stack. layer. Figure 3 illustrates IPv6 over DECT ULE stack.
As consequence of DECT ULE in it's primary configuration does not As consequence of DECT ULE in it's primary configuration does not
support the formation of multihop networks at the link layer, the support the formation of multihop networks at the link layer, the
mesh header defined in [RFC4944] for mesh under routing MUST NOT be 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 used. In addition, a DECT ULE PP node MUST NOT play the role of a
6LoWPAN Router (6LR). 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 data transmission over DECT ULE, a Permanent
Permanent Virtual Circuit (PVC) has to be opened between FP and PP. Virtual Circuit (PVC) has to be configured and opened between FP and
This MUST be done by setting up a service call from PP to FP. The PP PP. This is done by setting up a DECT service call from PP to FP.
SHALL specify the <<IWU-ATTRIBUTES>> in a service-change (other) In DECT protocol domain the PP SHALL specify the <<IWU-ATTRIBUTES>>
message before sending a service-change (resume) message as defined in a service-change (other) message before sending a service-change
in [TS102.939-1]. The <<IWU-ATTRIBTES>> SHALL define the ULE (resume) message as defined in [TS102.939-1]. The <<IWU-ATTRIBTES>>
Application Protocol Identifier to 0x06 and the MTU size to 1280 SHALL define the ULE Application Protocol Identifier to 0x06 and the
octets or larger. The FP MUST send a service-change-accept (resume) MTU size to 1280 octets or larger. The FP sends a service-change-
containing a valid paging descriptor. The PP MUST be pageable. accept (resume) that MUST contain a valid paging descriptor. The PP
MUST be pageable. Following this, transmission of IPv6 packets can
start.
+-------------------+ +-------------------+
| UDP/TCP/other | | UDP/TCP/other |
+-------------------+ +-------------------+
| IPv6 | | IPv6 |
+-------------------+ +-------------------+
|6LoWPAN adapted to | |6LoWPAN adapted to |
| DECT ULE | | DECT ULE |
+-------------------+ +-------------------+
| DECT ULE DLC | | DECT ULE DLC |
skipping to change at page 9, line 41 skipping to change at page 10, line 27
| 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 already fragmentation and layer 2. The DECT ULE implements already fragmentation and
reassembly functionality, hence [RFC4944] fragmentation and reassembly functionality, hence [RFC4944] fragmentation and
reassembly function MUST NOT be used. The DECT ULE DLC link (PVC) reassembly function MUST NOT be used.
MUST be configured with a minimum MTU size of at least 1280 octets in
order to meet the size requirements of IPv6. 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 6LBR ensures address collisions do not occur.
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 the DECT ULE star topology (see Section 2.2), PP each have a
to be an individual link and thus the PPs cannot directly hear one separate link to the FP, 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. As discussed in [RFC4903],
However, the FP acts as a 6LBR for communication between the PPs. conventional usage of IPv6 anticipates IPv6 subnets spanning a single
After the FP and PPs have connected at the DECT ULE level, the link link at the link layer. In order avoid the complexity of
can be considered up and IPv6 address configuration and transmission implementing separate subnet for each DECT ULE link, a Multi-Link
can begin. The FP ensures address collisions do not occur. Subnet model has been chosen, specifically Non-broadcast multi-access
(NBMA) at layer 2. Because of this, link-local multicast
communications can happen only within a single DECT ULE connection;
thus, 6LN-to-6LN communications using link-local addresses are not
possible. 6LNs connected to the same 6LBR have to communicate with
each other by using the shared prefix used on the subnet. The 6LBR
forwards packets sent by one 6LN to another.
3.2.1. Stateless Address Autoconfiguration 3.2.1. Stateless Address Autoconfiguration
At network interface initialization, both 6LN and 6LBR SHALL generate At network interface initialization, both 6LN and 6LBR SHALL generate
and assign to the DECT ULE network interface IPv6 link-local and assign to the DECT ULE network interface IPv6 link-local
addresses [RFC4862] based on the DECT device addresses (see addresses [RFC4862] based on the DECT device addresses (see
Section 2.3) that were used for establishing the underlying DECT ULE Section 2.3) that were used for establishing the underlying DECT ULE
connection. connection.
The DECT device addresses IPEI and RFPI MUST be used to derive the 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, IPv6 link-local 64 bit Interface Identifiers (IID) for 6LN and 6LBR,
respectively. respectively.
The rule for deriving IID from DECT device addresses is as follows: The rule for deriving IID from DECT device addresses is as follows:
The DECT device addresses that are consisting of 40 bits each, MUST The DECT device addresses that are consisting of 40 bits each, MUST
be expanded with leading zero bits to form 48 bit intermediate be expanded with leading zero bits to form 48 bit intermediate
addresses. Most significant bit in this newly formed 48-bit addresses. Most significant bit in this newly formed 48-bit
intermediate address is set to one for addresses derived from the intermediate address is set to one for addresses derived from the
RFPI and set to zero for addresses derived from the IPEI. From these RFPI and set to zero for addresses derived from the IPEI. From these
intermediate 48 bit addresses are derived 64 bit IIDs according to intermediate 48 bit addresses are derived 64 bit IIDs similar to the
the guidance of [RFC4291]. In the derived IIDs the U/L bit (7th bit) guidance of [RFC4291]. However, because DECT and IEEE address spaces
will be zero, indicating that derived IID's are not globally unique, are different, this intermediate address cannot be considered as
see [RFC7136]. For example from RFPI=11.22.33.44.55 the derived IID unique within IEEE address space. In the derived IIDs the U/L bit
is 80:11:22:ff:fe:33:44:55 and from IPEI=01.23.45.67.89 the derived (7th bit) will be zero, indicating that derived IID's are not
IID is 00:01:23:ff:fe:45:67:89. globally unique, see [RFC7136]. For example from RFPI=11.22.33.44.55
the derived IID is 80:11:22:ff:fe:33:44:55 and from
IPEI=01.23.45.67.89 the derived IID is 00:01:23:ff:fe:45:67:89.
As defined in [RFC4291], the IPv6 link-local address is formed by 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. appending the IID, to the prefix FE80::/64, as shown in Figure 4.
From privacy perspective such constructed link-local address should
never be used by application layers that could leak it outside the
subnet domain.
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, 6LNs SHOULD NOT be configured to use For non-link-local addresses, 6LNs SHOULD NOT be configured to use
IIDs derived from a MAC-48 device address or DECT device addresses. IIDs derived from a MAC-48 device address or DECT device addresses.
Alternative schemes such as Cryptographically Generated Addresses Alternative schemes such as Cryptographically Generated Addresses
(CGAs) [RFC3972], privacy extensions [RFC4941], Hash-Based Addresses (CGAs) [RFC3972], privacy extensions [RFC4941], Hash-Based Addresses
(HBAs) [RFC5535], DHCPv6 [RFC3315], or static, semantically opaque (HBAs) [RFC5535], DHCPv6 [RFC3315], or static, semantically opaque
addresses [RFC7217] SHOULD be used by default. In situations where addresses [RFC7217] SHOULD be used by default. See also [I-D.ietf-
the devices address embedded in the IID are required to support 6lo-privacy-considerations] for guidance of needed entropy in IIDs.
deployment constraints, 6LN MAY form a 64-bit IID by utilizing the In situations where the devices address embedded in the IID are
MAC-48 device address or DECT device addresses. The non-link-local required to support deployment constraints, 6LN MAY form a 64-bit IID
addresses 6LN generates MUST be registered with 6LBR as described in by utilizing the MAC-48 device address or DECT device addresses. The
Section 3.2.2. non-link-local addresses that a 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 address 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
[RFC6775] are applicable to DECT ULE 6LNs: [RFC6775] are applicable to DECT ULE 6LNs:
1. For sending Router Solicitations and processing Router 1. For sending Router Solicitations and processing Router
Advertisements the DECT ULE 6LNs MUST, respectively, follow Sections Advertisements the DECT ULE 6LNs MUST, respectively, follow Sections
5.3 and 5.4 of the [RFC6775]. 5.3 and 5.4 of the [RFC6775].
2. A DECT ULE 6LN MUST NOT register its link-local address. A DECT 2. A DECT ULE 6LN MUST NOT register its link-local address. Because
ULE 6LN MUST register its non-link-local addresses with the 6LBR by the IIDs used in link-local addresses are derived from DECT
sending a Neighbor Solicitation (NS) message with the Address addresses, there will always exist a unique mapping between link-
Registration Option (ARO) and process the Neighbor Advertisement (NA) local and layer-2 addresses.
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 3. A DECT ULE 6LN MUST register its non-link-local addresses with
IPv6 address per available IPv6 prefix. 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.
3.2.3. Unicast and Multicast Address Mapping 3.2.3. Unicast and Multicast Address Mapping
The DECT MAC layer broadcast service is considered inadequate for IP The DECT MAC layer broadcast service is considered inadequate for IP
multicast. multicast.
Hence traffic is always unicast between two DECT ULE nodes. Even in Hence traffic is always unicast between two DECT ULE nodes. Even in
the case where a 6LBR is attached to multiple 6LNs, the 6LBR cannot 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 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 a multicast packet to all its 6LNs, it has to replicate the packet
skipping to change at page 12, line 46 skipping to change at page 13, line 45
ARO and 6CO can be exploited in order to provide a mechanism for ARO and 6CO can be exploited in order to provide a mechanism for
address compression. The following text describes the principles of address compression. The following text describes the principles of
IPv6 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 used IPv6 source and destination addresses MUST be elided, since the used
IIDs map uniquely into the DECT link end point addresses. A 6LN or 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 6LBR that receives a PDU containing an IPv6 packet can infer the
corresponding IPv6 source address. For the type of communication corresponding IPv6 source address. For the unicast type of
considered in this paragraph, the following settings MUST be used in communication considered in this paragraph, the following settings
the IPv6 compressed header: CID=0, SAC=0, SAM=11, DAC=0, DAM=11. 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
6LNs global IPv6 address, the 6LN MUST indicate this context in the 6LNs global IPv6 address, the 6LN MUST indicate this context in the
corresponding source fields of the compressed IPv6 header as per corresponding source fields of the compressed IPv6 header as per
Section 3.1 of [RFC6282], and MUST elide the IPv6 source address. Section 3.1 of [RFC6282], and MUST fully elide the latest registered
For this, the 6LN MUST use the following settings in the IPv6 IPv6 source address. For this, the 6LN MUST use the following
compressed header: CID=1, SAC=1, SAM=11. In this case, the 6LBR can settings in the IPv6 compressed header: CID=1, SAC=1, SAM=11. In
infer the elided IPv6 source address since 1) the 6LBR has previously this case, the 6LBR can infer the elided IPv6 source address since 1)
assigned the prefix to the 6LNs; and 2) the 6LBR maintains a Neighbor the 6LBR has previously assigned the prefix to the 6LNs; and 2) the
Cache that relates the Device Address and the IID of the 6LBR maintains a Neighbor Cache that relates the Device Address and
corresponding PP. If a context is defined for the IPv6 destination the IID of the corresponding PP. If a context is defined for the
address, the 6LN MUST also indicate this context in the corresponding IPv6 destination address, the 6LN MUST also indicate this context in
destination fields of the compressed IPv6 header, and MUST elide the the corresponding destination fields of the compressed IPv6 header,
prefix of the destination IPv6 address. For this, the 6LN MUST set and MUST elide the prefix of the destination IPv6 address. For this,
the DAM field of the compressed IPv6 header as CID=1, DAC=1 and the 6LN MUST set the DAM field of the compressed IPv6 header as
DAM=01 or DAM=11. Note that when a context is defined for the IPv6 CID=1, DAC=1 and DAM=01 or DAM=11. Note that when a context is
destination address, the 6LBR can infer the elided destination prefix defined for the IPv6 destination address, the 6LBR can infer the
by using the context. elided destination prefix by using the context.
When a 6LBR receives a IPv6 packet having a global Unicast IPv6 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 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 defined for the prefix of the 6LN's global IPv6 address, the 6LBR
MUST indicate this context in the corresponding destination fields of MUST indicate this context in the corresponding destination fields of
the compressed IPv6 header, and MUST elide the IPv6 destination the compressed IPv6 header, and MUST fully elide the IPv6 destination
address of the packet before forwarding it to the 6LN. For this, the address of the packet if the destination address is the latest
6LBR MUST set the DAM field of the IPv6 compressed header as DAM=11. registered by the 6LN for the indicated context. For this, the 6LBR
CID and DAC MUST be set to CID=1 and DAC=1. If a context is defined MUST set the DAM field of the IPv6 compressed header as DAM=11. CID
for the prefix of the IPv6 source address, the 6LBR MUST indicate and DAC MUST be set to CID=1 and DAC=1. If a context is defined for
this context in the source fields of the compressed IPv6 header, and the prefix of the IPv6 source address, the 6LBR MUST indicate this
MUST elide that prefix as well. For this, the 6LBR MUST set the SAM context in the source fields of the compressed IPv6 header, and MUST
field of the IPv6 compressed header as CID=1, SAC=1 and SAM=01 or elide that prefix as well. For this, the 6LBR MUST set the SAM field
SAM=11. of the IPv6 compressed header as CID=1, SAC=1 and SAM=01 or 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 the DECT ULE star topology (see Section 2.2), PP each have a
Internet as shown in the Figure 5. In this scenario, the DECT ULE separate link to the FP and the FP acts as an IPv6 router rather than
network is deployed as one subnet, using one /64 IPv6 prefix. The a link-layer switch. A Multi-Link Subnet model [RFC4903] has been
6LBR is acting as router and forwarding packets between 6LNs and to chosen, specifically Non-broadcast multi-access (NBMA) at layer 2 as
and from Internet. further illustrated in Figure 5. The 6LBR forwards packets sent by
one 6LN to another. In a typical scenario, the DECT ULE network is
Other scenarios can be imagined where a PP is acting as 6LBR and connected to the Internet as shown in the Figure 5. In this
providing Internet connectivity for the FP. How the FP could then scenario, the DECT ULE network is deployed as one subnet, using one
further provide Internet connectivity to other PP, possibly connected /64 IPv6 prefix. The 6LBR is acting as router and forwarding packets
to the FP, is out of the scope of this document. between 6LNs and to and from Internet.
6LN 6LN
\ ____________ \ ____________
\ / \ \ / \
6LN ---- 6LBR --- | Internet | 6LN ---- 6LBR ------ | Internet |
/ \____________/ / \____________/
/ /
6LN 6LN
<-- DECT ULE --> <-- One subnet -->
<-- DECT ULE -->
Figure 5: DECT ULE network connected to the Internet Figure 5: DECT ULE network connected to the Internet
In some scenarios, the DECT ULE network may transiently or In some scenarios, the DECT ULE network may transiently or
permanently be an isolated network as shown in the Figure 6. In this 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 case the whole DECT ULE network consists of a single subnet with
multiple links, where 6LBR is routing packets between 6LNs. multiple links, where 6LBR is routing packets between 6LNs.
6LN 6LN 6LN 6LN
\ / \ /
\ / \ /
6LN --- 6LBR --- 6LN 6LN --- 6LBR --- 6LN
/ \ / \
/ \ / \
6LN 6LN 6LN 6LN
<---- One subnet ---->
<------ DECT ULE -----> <------ DECT ULE ----->
Figure 6: Isolated DECT ULE network Figure 6: Isolated DECT ULE network
In the isolated network scenario, communications between 6LN and 6LBR In the isolated network scenario, communications between 6LN and 6LBR
can use IPv6 link-local methodology, but for communications between can use IPv6 link-local methodology, but for communications between
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.
In other more advanced systems scenarios with multiple FP and 6LBR,
each DECT ULE FP constitutes a wireless cell. The network can be
configured as a Multi-Link Subnet, in which the can 6LN operate
within the same /64 subnet prefix in multiple cells as shown in the
Figure 7. The FPs operation role in such scenario are rather like
Backbone Routers (6BBR) than 6LBR, as per [I-D.ietf-6lo-backbone-
router].
____________
/ \
| Internet |
\____________/
|
|
|
|
6BBR/ | 6BBR/
6LN ---- 6LBR -------+------- 6LBR ---- 6LN
/ \ / \
/ \ / \
6LN 6LN 6LN 6LN
<------------------One subnet ------------------>
<-- DECT ULE Cell --> <-- DECT ULE Cell -->
Figure 7: Multiple DECT ULE cells in a single Multi-Link subnet
4. IANA Considerations 4. IANA Considerations
There are no IANA considerations related to this document. There are no IANA considerations related to this document.
5. Security Considerations 5. Security Considerations
The secure transmission of speech over DECT will be based on the The secure transmission of speech over DECT will be based on the
DSAA2 and DSC/DSC2 specification developed by ETSI TC DECT and the DSAA2 and DSC/DSC2 specification developed by ETSI TC DECT and the
ETSI SAGE Security expert group. ETSI SAGE Security expert group.
skipping to change at page 15, line 34 skipping to change at page 17, line 15
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.
From privacy point of view, the IPv6 link-local address configuration From privacy point of view, the IPv6 link-local address configuration
described in Section 3.2.1 only reveals information about the 6LN to 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. 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 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- randomly generated IID, for example, as discussed in [I-D.ietf-6man-
default- iids], or use alternative schemes such as Cryptographically default-iids], or use alternative schemes such as Cryptographically
Generated Addresses (CGA) [RFC3972], privacy extensions [RFC4941], Generated Addresses (CGA) [RFC3972], privacy extensions [RFC4941],
Hash-Based Addresses (HBA, [RFC5535]), or static, semantically opaque Hash-Based Addresses (HBA, [RFC5535]), or static, semantically opaque
addresses [RFC7217]. 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
skipping to change at page 16, line 10 skipping to change at page 17, line 39
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, Samita Chakrabarti and Kerry Lynn have provided valuable Ralph Droms, Samita Chakrabarti, Kerry Lynn, Suresh Krishnan and
feedback for this draft. Pascal Thubert 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/ <https://www.etsi.org/deliver/
etsi_en/300100_300199/30017501/02.06.01_60/ etsi_en/300100_300199/30017501/02.06.01_60/
skipping to change at page 18, line 5 skipping to change at page 19, line 32
etsi_ts/102900_102999/10293902/01.01.01_60/ etsi_ts/102900_102999/10293902/01.01.01_60/
ts_10293902v010101p.pdf>. ts_10293902v010101p.pdf>.
8.2. Informative References 8.2. Informative References
[CAT-iq] DECT Forum, "Cordless Advanced Technology - internet and [CAT-iq] DECT Forum, "Cordless Advanced Technology - internet and
quality", January 2016, quality", January 2016,
<http://www.dect.org/userfiles/Public/ <http://www.dect.org/userfiles/Public/
DF_CAT-iq%20Certification%20Overview.pdf>. DF_CAT-iq%20Certification%20Overview.pdf>.
[I-D.ietf-6lo-backbone-router]
Thubert, P., "IPv6 Backbone Router", draft-ietf-6lo-
backbone-router-02 (work in progress), September 2016.
[I-D.ietf-6lo-privacy-considerations]
Thaler, D., "Privacy Considerations for IPv6 over Networks
of Resource-Constrained Nodes", draft-ietf-6lo-privacy-
considerations-03 (work in progress), September 2016.
[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-16 (work in progress),
September 2016.
[RFC3315] Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins, [RFC3315] Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins,
C., and M. Carney, "Dynamic Host Configuration Protocol C., and M. Carney, "Dynamic Host Configuration Protocol
for IPv6 (DHCPv6)", RFC 3315, DOI 10.17487/RFC3315, July for IPv6 (DHCPv6)", RFC 3315, DOI 10.17487/RFC3315, July
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>.
[RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)", [RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)",
RFC 3972, DOI 10.17487/RFC3972, March 2005, RFC 3972, DOI 10.17487/RFC3972, March 2005,
<http://www.rfc-editor.org/info/rfc3972>. <http://www.rfc-editor.org/info/rfc3972>.
[RFC4903] Thaler, D., "Multi-Link Subnet Issues", RFC 4903,
DOI 10.17487/RFC4903, June 2007,
<http://www.rfc-editor.org/info/rfc4903>.
[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>.
 End of changes. 42 change blocks. 
181 lines changed or deleted 263 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/