Internet Engineering Task Force (IETF) P. Mariager
Request for Comments: 8105 J. Petersen, Ed.
Category: Standards Track RTX A/S
ISSN: 2070-1721 Z. Shelby
ARM
M. van de Logt
Bosch Sensortec GmbH
D. Barthel
Orange Labs
May 2017
Internet Engineering Task Force (IETF) P. Mariager
Request for Comments: 8105 J. Petersen, Ed.
Category: Standards Track RTX A/S
ISSN: 2070-1721 Z. Shelby
ARM
M. van de Logt
Bosch Sensortec GmbH
D. Barthel
Orange Labs
May 2017
Transmission of IPv6 Packets over Digital Enhanced Cordless Telecommunications (DECT) Ultra Low Energy (ULE)
通过数字增强无绳通信（DECT）超低能量（ULE）传输IPv6数据包
Abstract
摘要
Digital Enhanced Cordless Telecommunications (DECT) Ultra Low Energy (ULE) is a low-power air interface technology that is proposed by the DECT Forum and is defined and specified by ETSI.
数字增强无绳通信（DECT）超低能（ULE）是由DECT论坛提出并由ETSI定义和指定的一种低功耗空中接口技术。
The DECT air interface technology has been used worldwide in communication devices for more than 20 years. It has primarily been used to carry voice for cordless telephony but has also been deployed for data-centric services.
DECT空中接口技术在全球通信设备中的应用已有20多年的历史。它主要用于无绳电话的语音传输，但也用于以数据为中心的服务。
DECT ULE is a recent addition to the DECT interface primarily intended for low-bandwidth, low-power applications such as sensor devices, smart meters, home automation, etc. As the DECT ULE interface inherits many of the capabilities from DECT, it benefits from operation that is long-range and interference-free, worldwide-reserved frequency band, low silicon prices, and maturity. There is an added value in the ability to communicate with IPv6 over DECT ULE, such as for Internet of Things applications.
DECT-ULE是DECT接口的最新添加，主要用于低带宽、低功耗应用，如传感器设备、智能仪表、家庭自动化等。由于DECT-ULE接口继承了DECT的许多功能，因此它得益于远距离、无干扰、全球保留频带的操作，低硅价格和成熟度。通过数据与IPv6通信的能力具有附加价值，例如用于物联网应用。
This document describes how IPv6 is transported over DECT ULE using IPv6 over Low-Power Wireless Personal Area Network (6LoWPAN) techniques.
本文档描述了如何使用低功耗无线个人区域网（6LoWPAN）技术在DECT上传输IPv6。
Status of This Memo
关于下段备忘
This is an Internet Standards Track document.
这是一份互联网标准跟踪文件。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。有关互联网标准的更多信息，请参见RFC 7841第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc8105.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc8105.
Copyright Notice
版权公告
Copyright (c) 2017 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2017 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Requirements Notation . . . . . . . . . . . . . . . . . . 5
1.2. Terms Used . . . . . . . . . . . . . . . . . . . . . . . 5
2. DECT Ultra Low Energy . . . . . . . . . . . . . . . . . . . . 6
2.1. The DECT ULE Protocol Stack . . . . . . . . . . . . . . . 6
2.2. Link Layer Roles and Topology . . . . . . . . . . . . . . 8
2.3. Addressing Model . . . . . . . . . . . . . . . . . . . . 8
2.4. MTU Considerations . . . . . . . . . . . . . . . . . . . 9
2.5. Additional Considerations . . . . . . . . . . . . . . . . 9
3. Specification of IPv6 over DECT ULE . . . . . . . . . . . . . 9
3.1. Protocol Stack . . . . . . . . . . . . . . . . . . . . . 10
3.2. Link Model . . . . . . . . . . . . . . . . . . . . . . . 11
3.3. Subnets and Internet Connectivity Scenarios . . . . . . . 15
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
5. Security Considerations . . . . . . . . . . . . . . . . . . . 17
6. ETSI Considerations . . . . . . . . . . . . . . . . . . . . . 18
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 18
7.1. Normative References . . . . . . . . . . . . . . . . . . 18
7.2. Informative References . . . . . . . . . . . . . . . . . 20
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 21
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Requirements Notation . . . . . . . . . . . . . . . . . . 5
1.2. Terms Used . . . . . . . . . . . . . . . . . . . . . . . 5
2. DECT Ultra Low Energy . . . . . . . . . . . . . . . . . . . . 6
2.1. The DECT ULE Protocol Stack . . . . . . . . . . . . . . . 6
2.2. Link Layer Roles and Topology . . . . . . . . . . . . . . 8
2.3. Addressing Model . . . . . . . . . . . . . . . . . . . . 8
2.4. MTU Considerations . . . . . . . . . . . . . . . . . . . 9
2.5. Additional Considerations . . . . . . . . . . . . . . . . 9
3. Specification of IPv6 over DECT ULE . . . . . . . . . . . . . 9
3.1. Protocol Stack . . . . . . . . . . . . . . . . . . . . . 10
3.2. Link Model . . . . . . . . . . . . . . . . . . . . . . . 11
3.3. Subnets and Internet Connectivity Scenarios . . . . . . . 15
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
5. Security Considerations . . . . . . . . . . . . . . . . . . . 17
6. ETSI Considerations . . . . . . . . . . . . . . . . . . . . . 18
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 18
7.1. Normative References . . . . . . . . . . . . . . . . . . 18
7.2. Informative References . . . . . . . . . . . . . . . . . 20
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 21
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22
Digital Enhanced Cordless Telecommunications (DECT) is a standard series [EN300.175-part1-7] specified by ETSI, and CAT-iq (Cordless Advanced Technology - internet and quality) is a set of product certification and interoperability profiles [CAT-iq] defined by DECT Forum. DECT Ultra Low Energy (DECT ULE or just ULE) is an air interface technology building on the key fundamentals of traditional DECT/CAT-iq but with specific changes to significantly reduce the power consumption at the expense of data throughput. DECT ULE devices with requirements on power consumption, as specified by ETSI in [TS102.939-1] and [TS102.939-2], will operate on special power-optimized silicon but can connect to a DECT Gateway supporting traditional DECT/CAT-iq for cordless telephony and data as well as the ULE extensions.
数字增强无绳通信（DECT）是ETSI指定的标准系列[EN300.175-part1-7]，CAT iq（无绳高级技术-互联网和质量）是DECT论坛定义的一套产品认证和互操作性配置文件[CAT iq]。DECT超低能量（DECT ULE或just ULE）是一种基于传统DECT/CAT iq关键基础的空中接口技术，但经过了特定的更改，以显著降低功耗，同时牺牲数据吞吐量。ETSI在[TS102.939-1]和[TS102.939-2]中规定的对功耗有要求的DECT ULE设备将在特殊的功率优化硅上运行，但可以连接到支持传统DECT/CAT iq的DECT网关，用于无绳电话和数据以及ULE扩展。
DECT terminology has two major role definitions: the Portable Part (PP) is the power-constrained device while the Fixed Part (FP) is the Gateway or base station. This FP may be connected to the Internet. An example of a use case for DECT ULE is a home-security sensor transmitting small amounts of data (few bytes) at periodic intervals through the FP but that is able to wake up upon an external event (e.g., a break-in) and communicate with the FP. Another example incorporating both DECT ULE and traditional CAT-iq telephony would be a pendant (brooch) for the elderly that generally transmits periodic status messages to a care provider using very little battery, but in the event of an emergency, the elderly person can establish a voice connection through the pendant to an alarm service. It is expected that DECT ULE will be integrated into many residential gateways, as many of these already implement DECT CAT-iq for cordless telephony. DECT ULE can be added as a software option for the FP.
DECT术语有两个主要角色定义：便携式部分（PP）是功率受限设备，而固定部分（FP）是网关或基站。此FP可能连接到Internet。DECT ULE用例的一个示例是家庭安全传感器，该传感器以周期性间隔通过FP传输少量数据（几个字节），但能够在外部事件（例如，入侵）时唤醒并与FP通信。另一个结合DECT-ULE和传统CAT iq电话的例子是一个老人挂件（胸针），它通常使用很少的电池向护理提供者发送定期状态信息，但在紧急情况下，老人可以通过挂件与报警服务建立语音连接。预计DECT ULE将集成到许多住宅网关中，因为其中许多已经实现了用于无绳电话的DECT CAT iq。DECT ULE可以作为FP的软件选项添加。
It is desirable to consider IPv6 for DECT ULE devices due to the large address space and well-known infrastructure. This document describes how IPv6 is used on DECT ULE links to optimize power while maintaining the many benefits of IPv6 transmission. [RFC4944], [RFC6282], and [RFC6775] specify the transmission of IPv6 over IEEE 802.15.4. DECT ULE has many characteristics similar to those of IEEE 802.15.4, but it also has differences. A subset of mechanisms defined for transmission of IPv6 over IEEE 802.15.4 can be applied to the transmission of IPv6 on DECT ULE links.
由于大的地址空间和众所周知的基础设施，需要考虑IPv6对DETULE设备的影响。本文档介绍如何在数据链路上使用IPv6来优化电源，同时保持IPv6传输的诸多好处。[RFC4944]、[RFC6282]和[RFC6775]指定通过IEEE 802.15.4传输IPv6。DECT ULE具有许多与IEEE 802.15.4相似的特性，但也存在差异。为通过IEEE 802.15.4传输IPv6而定义的机制子集可应用于在特定链路上传输IPv6。
This document specifies how to map IPv6 over DECT ULE inspired by [RFC4944], [RFC6282], [RFC6775], and [RFC7668].
本文档指定了如何在[RFC4944]、[RFC6282]、[RFC6775]和[RFC7668]的启发下将IPv6映射到DECT上。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“建议”、“不建议”、“可”和“可选”应按照[RFC2119]中的说明进行解释。
6CO 6LoWPAN Context Option [RFC6775]
6BBR 6loWPAN Backbone Router
6LBR 6LoWPAN Border Router, as defined in [RFC6775].
The DECT Fixed Part has this role.
6LN 6LoWPAN Node as defined in [RFC6775].
The DECT Portable Part has this role
6LoWPAN IPv6 over Low-Power Wireless Personal Area Network
AES128 Advanced Encryption Standard with a key size of 128 bits
API Application Programming Interface
ARO Address Registration Option [RFC6775]
CAT-iq Cordless Advanced Technology - internet and quality
CID Context Identifier [RFC6775]
DAC Destination Address Compression
DAD Duplicate Address Detection [RFC4862]
DAM Destination Address Mode
DHCPv6 Dynamic Host Configuration Protocol for IPv6 [RFC3315]
DLC Data Link Control
DSAA2 DECT Standard Authentication Algorithm #2
DSC DECT Standard Cipher
DSC2 DECT Standard Cipher #2
FDMA Frequency-Division Multiple Access
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
NBMA Non-Broadcast Multi-Access
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
6CO 6LoWPAN Context Option [RFC6775]
6BBR 6loWPAN Backbone Router
6LBR 6LoWPAN Border Router, as defined in [RFC6775].
The DECT Fixed Part has this role.
6LN 6LoWPAN Node as defined in [RFC6775].
The DECT Portable Part has this role
6LoWPAN IPv6 over Low-Power Wireless Personal Area Network
AES128 Advanced Encryption Standard with a key size of 128 bits
API Application Programming Interface
ARO Address Registration Option [RFC6775]
CAT-iq Cordless Advanced Technology - internet and quality
CID Context Identifier [RFC6775]
DAC Destination Address Compression
DAD Duplicate Address Detection [RFC4862]
DAM Destination Address Mode
DHCPv6 Dynamic Host Configuration Protocol for IPv6 [RFC3315]
DLC Data Link Control
DSAA2 DECT Standard Authentication Algorithm #2
DSC DECT Standard Cipher
DSC2 DECT Standard Cipher #2
FDMA Frequency-Division Multiple Access
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
NBMA Non-Broadcast Multi-Access
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 Multiple Access TPUI Temporary Portable User Identity; DECT identity UAK User Authentication Key; DECT master security key ULA Unique Local Address [RFC4193]
时分多址TPUI临时便携式用户标识；DECT身份UAK用户认证密钥；DECT主安全密钥唯一本地地址[RFC4193]
DECT ULE is a low-power air interface technology that is designed to support both circuit-switched services, such as voice communication, and packet-mode data services at a modest data rate. This document is only addressing the packet-mode data service of DECT ULE.
DECT ULE是一种低功耗空中接口技术，旨在以适度的数据速率支持电路交换服务（如语音通信）和分组模式数据服务。本文档仅针对DECT ULE的分组模式数据服务。
The DECT ULE Protocol Stack contains a PHY layer operating at frequencies in the 1880 - 1920 MHz frequency band depending on the region and uses a symbol rate of 1.152 Mbaud. Radio bearers are allocated by use of FDMA/TDMA/TDD techniques.
DECT ULE协议栈包含一个PHY层，其工作频率为1880-1920 MHz，具体取决于区域，并使用1.152 Mbaud的符号速率。无线承载通过使用FDMA/TDMA/TDD技术来分配。
In its generic network topology, DECT is defined as a cellular network technology. However, the most common configuration is a star network with a single FP defining the network with a number of PPs attached. The MAC layer supports both traditional DECT circuit mode operation, as this is used for services like discovery, pairing, security features, etc., and it supports new ULE packet-mode operation. The circuit-mode features have been reused from DECT.
在其通用网络拓扑中，DECT被定义为蜂窝网络技术。但是，最常见的配置是星形网络，其中单个FP定义了连接了多个PP的网络。MAC层支持传统的DECT电路模式操作，因为它用于发现、配对、安全功能等服务，并且支持新的ULE分组模式操作。电路模式功能已从DECT中重新使用。
The DECT ULE device can switch to the ULE mode of operation, utilizing the new ULE MAC layer features. The DECT ULE Data Link Control (DLC) provides multiplexing as well as segmentation and reassembly for larger packets from layers above. The DECT ULE layer also implements per-message authentication and encryption. The DLC layer ensures packet integrity and preserves packet order, but delivery is based on best effort.
DECT ULE设备可以利用新的ULE MAC层功能切换到ULE操作模式。数据链路控制（DLC）为上层的较大数据包提供多路复用、分段和重新组装。DECT-ULE层还实现了每条消息的身份验证和加密。数据链路层确保数据包的完整性并保持数据包的顺序，但传输是基于最大努力的。
The current DECT ULE MAC layer standard supports low-bandwidth data broadcast. However, this document is not considering usage of the DECT ULE MAC layer broadcast service for IPv6 over DECT ULE.
当前的DECT ULE MAC层标准支持低带宽数据广播。但是，本文档不考虑在DECT ULE上使用用于IPv6的DECT ULE MAC层广播服务。
In general, communication sessions can be initiated from both the FP side and the PP side. Depending on power-down modes employed in the PP, latency may occur when initiating sessions from the FP side. MAC layer communication can take place using either connection-oriented packet transfer with low overhead for short sessions or connection-oriented bearers including media reservation. The MAC layer autonomously selects the radio-spectrum positions that are available
通常，通信会话可以从FP侧和PP侧发起。根据PP中采用的断电模式，从FP端启动会话时可能会出现延迟。MAC层通信可以使用短会话的低开销的面向连接的数据包传输或包括媒体保留的面向连接的承载来进行。MAC层自动选择可用的无线电频谱位置
within the band and can rearrange these to avoid interference. The MAC layer has built-in retransmission procedures in order to improve transmission reliability.
在频带内，可以重新排列这些以避免干扰。MAC层具有内置的重传过程，以提高传输可靠性。
The DECT ULE device will typically incorporate an Application Programming Interface (API), as well as common elements known as Generic Access Profiles (GAPs), for enrolling into the network. The DECT ULE Stack establishes a Permanent Virtual Circuit (PVC) for the application layers and provides support for a range of different application protocols. The application protocol is negotiated between the PP and FP when the PVC communication service is established. [TS102.939-1] defines this negotiation and specifies an Application Protocol Identifier set to 0x06 for 6LoWPAN. This document defines the behavior of that application protocol.
DECT-ULE设备通常包含一个应用程序编程接口（API）以及通用访问配置文件（GAPs）的通用元素，用于注册到网络中。DECT ULE堆栈为应用层建立了一个永久虚拟电路（PVC），并为一系列不同的应用协议提供支持。当PVC通信服务建立时，PP和FP之间协商应用程序协议。[TS102.939-1]定义此协商，并为6LoWPAN指定设置为0x06的应用协议标识符。本文档定义了该应用程序协议的行为。
+----------------------------------------+
| Application Layers |
+----------------------------------------+
| Generic Access | ULE Profile |
| Profile | |
+----------------------------------------+
| DECT/Service API | ULE Data API |
+--------------------+-------------------+
| LLME | NWK (MM,CC)| |
+--------------------+-------------------+
| DECT DLC | DECT ULE DLC |
+--------------------+-------------------+
| MAC Layer |
+--------------------+-------------------+
| PHY Layer |
+--------------------+-------------------+
(C-plane) (U-plane)
+----------------------------------------+
| Application Layers |
+----------------------------------------+
| Generic Access | ULE Profile |
| Profile | |
+----------------------------------------+
| DECT/Service API | ULE Data API |
+--------------------+-------------------+
| LLME | NWK (MM,CC)| |
+--------------------+-------------------+
| DECT DLC | DECT ULE DLC |
+--------------------+-------------------+
| MAC Layer |
+--------------------+-------------------+
| PHY Layer |
+--------------------+-------------------+
(C-plane) (U-plane)
Figure 1: DECT ULE Protocol Stack
图1:DECT-ULE协议栈
Figure 1 shows the DECT ULE Stack divided into the Control Plane (C-plane) and User Data Plane (U-plane), to the left and to the right, respectively. The shown entities in the Stack are the Physical Layer (PHY), Media Access Control (MAC) Layer, Data Link Control (DLC) Layer, and Network Layer (NWK), along with following subcomponents: Lower-Layer Management Entity (LLME), Mobility Management (MM), and Call Control (CC). Above there are the typical Application Programmers Interface (API) and application-profile-specific layers.
图1显示了分别向左和向右划分为控制平面（C平面）和用户数据平面（U平面）的数据块堆栈。堆栈中显示的实体是物理层（PHY）、媒体访问控制（MAC）层、数据链路控制（DLC）层和网络层（NWK），以及以下子组件：下层管理实体（LLME）、移动性管理（MM）和呼叫控制（CC）。上面是典型的应用程序编程接口（API）和特定于应用程序概要文件的层。
An FP is assumed to be less constrained than a PP. Hence, in the primary scenario, the FP and PP will act as 6LBR and a 6LN, respectively. This document only addresses this primary scenario, and all other scenarios with different roles of an FP and PP are out of scope.
假设FP的约束比PP小。因此，在主要场景中，FP和PP将分别充当6LBR和6LN。本文档仅讨论此主要场景，具有FP和PP不同角色的所有其他场景均不在范围内。
In DECT ULE, at the link layer, the communication only takes place between an FP and a PP. An FP is able to handle multiple simultaneous connections with a number of PPs. Hence, in a DECT ULE network using IPv6, a radio hop is equivalent to an IPv6 link and vice versa (see Section 3.3).
在十二月，在链路层，通信仅发生在FP和PP之间。FP能够处理多个PP的多个同时连接。因此，在使用IPv6的DECT ULE网络中，无线跃点相当于IPv6链路，反之亦然（见第3.3节）。
[DECT ULE PP]-----\ /-----[DECT ULE PP]
\ /
[DECT ULE PP]-------+[DECT ULE FP]+-------[DECT ULE PP]
/ \
[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 PP]
Figure 2: DECT ULE Star Topology
图2：DECT-ULE星形拓扑
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 its primary configuration does not support the formation of multihop networks at the link layer. In consequence, the mesh header defined in [RFC4944] is not used in DECT ULE networks.
IEEE 802.15.4和DECT ULE之间的一个显著区别是前者支持星形和网状拓扑（并且需要路由协议），而DECT ULE在其主要配置中不支持在链路层形成多跳网络。因此，[RFC4944]中定义的网格标头不用于DECT ULE网络。
DECT ULE repeaters are considered to operate transparently in the DECT protocol domain and are outside the scope of this document.
DECT规则中继器被视为在DECT协议域中透明运行，不在本文档范围内。
Each DECT PP is assigned an IPEI during manufacturing. This identity has the size of 40 bits and is globally unique within DECT addressing space and can be used to constitute the MAC address used to derive the IID for link-local address.
每个DECT PP在制造过程中分配一个IPEI。该标识的大小为40位，在DECT寻址空间内是全局唯一的，可用于构成MAC地址，用于导出链路本地地址的IID。
During a DECT location registration procedure, the FP assigns a 20-bit TPUI to a PP. The FP creates a unique mapping between the assigned TPUI and the IPEI of each PP. This TPUI is used for addressing (Layer 2) in messages between the FP and PP. Although the TPUI is temporary by definition, many implementations assign the same value repeatedly to any given PP, hence it seems not suitable for construction of the IID (see [RFC8065]).
在DECT位置注册过程中，FP向PP分配一个20位TPUI。FP在分配的TPUI和每个PP的IPEI之间创建一个唯一的映射。该TPUI用于在FP和PP之间的消息中寻址（第2层）。尽管TPUI在定义上是临时的，许多实现将相同的值重复分配给任何给定的PP，因此它似乎不适合IID的构造（请参见[RFC8065]）。
Each DECT FP is assigned an RFPI during manufacturing. This identity has the size of 40 bits and is globally unique within DECT addressing space and can be used to constitute the MAC address used to derive the IID for link-local address.
每个DECT FP在制造过程中分配一个RFPI。该标识的大小为40位，在DECT寻址空间内是全局唯一的，可用于构成MAC地址，用于导出链路本地地址的IID。
Optionally, each DECT PP and DECT FP can be assigned a unique (IEEE) MAC-48 address in addition to the DECT identities to be used by the 6LoWPAN. During the address registration of non-link-local addresses as specified by this document, the FP and PP can use such MAC-48 to construct the IID. However, as these addresses are considered as being permanent, such a scheme is NOT RECOMMENDED as per [RFC8065].
除6LoWPAN使用的DECT标识外，还可以为每个DECT PP和DECT FP分配一个唯一的（IEEE）MAC-48地址。在本文件规定的非链路本地地址的地址注册期间，FP和PP可以使用这种MAC-48来构建IID。但是，由于这些地址被视为永久地址，因此根据[RFC8065]，不建议采用这种方案。
Ideally, the DECT ULE FP and PP may generate data that fits into a single MAC layer packet (38 octets) for periodically transferred information, depending on application. However, IP packets may be much larger. The DECT ULE DLC procedures natively support segmentation and reassembly and provide any MTU size below 65536 octets. The default MTU size defined in DECT ULE [TS102.939-1] is 500 octets. In order to support complete IPv6 packets, the DLC layer of DECT ULE SHALL, per this specification, be configured with an MTU size of 1280 octets, hence [RFC4944] fragmentation/reassembly is not required.
理想情况下，DECT ULE FP和PP可以根据应用生成适合周期性传输信息的单个MAC层分组（38个八位字节）的数据。然而，IP数据包可能要大得多。DECT ULE DLC程序本机支持分段和重新组装，并提供任何小于65536个八位字节的MTU大小。12条[TS102.939-1]中定义的默认MTU大小为500个八位字节。为了支持完整的IPv6数据包，根据本规范，DECT ULE的DLC层应配置1280个八位字节的MTU大小，因此不需要[RFC4944]分段/重组。
It is important to realize that the usage of larger packets will be at the expense of battery life, as a large packet inside the DECT ULE Stack will be fragmented into several or many MAC layer packets, each consuming power to transmit/receive. The increased MTU size does not change the MAC layer packet and PDU size.
重要的是要认识到，使用较大的数据包将以牺牲电池寿命为代价，因为数据包堆栈中的一个较大数据包将被分割成几个或多个MAC层数据包，每个数据包都会消耗发送/接收的功率。增加的MTU大小不会改变MAC层分组和PDU大小。
The DECT ULE standard allows the PP to be DECT-registered (bound) to multiple FP and to roam between them. These FP and their 6LBR functionalities can operate either individually or connected through a Backbone Router as per [BACKBONE-ROUTER].
DECT ULE标准允许将PP DECT注册（绑定）到多个FP并在它们之间漫游。这些FP及其6LBR功能可以单独运行，也可以根据[主干路由器]通过主干路由器连接。
Before any IP-layer communications can take place over DECT ULE, DECT-ULE-enabled nodes such as 6LNs and 6LBRs have to find each other and establish a suitable link layer connection. The obtain-access-rights registration and location registration procedures are documented by ETSI in the specifications [EN300.175-part1-7], [TS102.939-1], and [TS102.939-2].
在通过DECT ULE进行任何IP层通信之前，支持DECT ULE的节点（如6LNs和6LBRs）必须找到彼此并建立适当的链路层连接。ETSI在规范[EN300.175-part1-7]、[TS102.939-1]和[TS102.939-2]中记录了获取访问权注册和位置注册程序。
DECT ULE technology sets strict requirements for low power consumption and, thus, limits the allowed protocol overhead. 6LoWPAN standards [RFC4944], [RFC6775], and [RFC6282] provide useful functionality for reducing overhead that can be applied to DECT ULE. This functionality comprises link-local IPv6 addresses and stateless IPv6 address autoconfiguration, Neighbor Discovery, and header compression.
DECT ULE技术对低功耗提出了严格要求，因此限制了允许的协议开销。6 LowPan标准[RFC4944]、[RFC6775]和[RFC6282]提供了用于减少可应用于DECT的开销的有用功能。此功能包括链路本地IPv6地址和无状态IPv6地址自动配置、邻居发现和报头压缩。
The ULE 6LoWPAN adaptation layer can run directly on this U-plane DLC layer. Figure 3 illustrates an IPv6 over DECT ULE Stack.
ULE 6LoWPAN适配层可以直接在该U面DLC层上运行。图3展示了一个IPv6 over DECT-ULE堆栈。
Because DECT ULE in its primary configuration does not support the formation of multihop networks at the link layer, the mesh header defined in [RFC4944] for mesh under routing MUST NOT be used. In addition, the role of a 6LoWPAN Router (6LR) is not defined per this specification.
由于DECT ULE在其主要配置中不支持在链路层形成多跳网络，因此不得使用[RFC4944]中为正在路由的mesh定义的mesh标头。此外，本规范未定义6LoWPAN路由器（6LR）的作用。
In order to enable data transmission over DECT ULE, a Permanent Virtual Circuit (PVC) has to be configured and opened between the FP and PP. This is done by setting up a DECT service call between the PP and FP. In the DECT protocol domain, the PP SHALL specify the <<IWU-ATTRIBUTES>> in a service-change (other) message before sending a service-change (resume) message as defined in [TS102.939-1]. The <<IWU-ATTRIBUTES>> SHALL set the ULE Application Protocol Identifier to 0x06 and the MTU size to 1280 octets or larger. The FP sends a service-change-accept (resume) that MUST contain a valid paging descriptor. The PP MUST listen to paging messages from the FP according to the information in the received paging descriptor. Following this, transmission of IPv6 packets can start.
为了通过DECT ULE实现数据传输，必须在FP和PP之间配置并打开永久虚拟电路（PVC）。这是通过在PP和FP之间设置DECT服务调用来实现的。在DECT协议域中，PP应在发送[TS102.939-1]中定义的服务变更（恢复）消息之前，在服务变更（其他）消息中指定<<IWU-属性>>。<IWU-ATTRIBUTES>>应将ULE应用协议标识符设置为0x06，将MTU大小设置为1280个八位字节或更大。FP发送必须包含有效分页描述符的服务更改接受（恢复）。PP必须根据接收到的分页描述符中的信息侦听来自FP的分页消息。在此之后，可以开始IPv6数据包的传输。
+-------------------+
| UDP/TCP/other |
+-------------------+
| IPv6 |
+-------------------+
|6LoWPAN adapted to |
| DECT ULE |
+-------------------+
| DECT ULE DLC |
+-------------------+
| DECT ULE MAC |
+-------------------+
| DECT ULE PHY |
+-------------------+
+-------------------+
| UDP/TCP/other |
+-------------------+
| IPv6 |
+-------------------+
|6LoWPAN adapted to |
| DECT ULE |
+-------------------+
| DECT ULE DLC |
+-------------------+
| DECT ULE MAC |
+-------------------+
| DECT ULE PHY |
+-------------------+
Figure 3: IPv6 over DECT ULE Stack
图3:IPv6 over DECT-ULE堆栈
The general model is that IPv6 is Layer 3 and DECT ULE MAC and DECT ULE DLC are Layer 2. DECT ULE already implements fragmentation and reassembly functionality; hence, the fragmentation and reassembly function described in [RFC4944] MUST NOT be used.
一般模型是IPv6是第3层，DECT ULE MAC和DECT ULE DLC是第2层。DECT ULE已经实现了碎片和重组功能；因此，不得使用[RFC4944]中描述的碎片和重新组装功能。
After the FPs 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.
FPs和PPs在DECT ULE级别连接后，可以认为链路已建立，IPv6地址配置和传输可以开始。6LBR确保不会发生地址冲突。
Per this specification, the IPv6 header compression format specified in [RFC6282] MUST be used. The IPv6 payload length can be derived from the ULE DLC packet length. The possibly elided IPv6 address can be reconstructed from the lower layer address (see Section 3.2.4).
根据本规范，必须使用[RFC6282]中指定的IPv6标头压缩格式。IPv6有效负载长度可以从ULE DLC数据包长度中导出。可能省略的IPv6地址可以从较低层地址重建（见第3.2.4节）。
Due to the DECT ULE star topology (see Section 2.2), each PP has a separate link to the FP; thus, the PPs cannot directly hear one another and cannot talk to one another. As discussed in [RFC4903], conventional usage of IPv6 anticipates IPv6 subnets spanning a single link at the link layer. In order to avoid the complexity of implementing a separate subnet for each DECT ULE link, a Multi-Link Subnet model [RFC4903] 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 utilizing the shared prefix used on the subnet. The 6LBR forwards packets sent by one 6LN to another.
由于DECT ULE星形拓扑（见第2.2节），每个PP都有一个到FP的单独链接；因此，PPs不能直接听到彼此的声音，也不能相互交谈。如[RFC4903]中所述，IPv6的传统用法预期IPv6子网在链路层跨越单个链路。为了避免为每个数据链路实现单独子网的复杂性，选择了多链路子网模型[RFC4903]，特别是第2层的非广播多址（NBMA）。因此，链路本地多播通信只能在单个数据块连接内发生；因此，不可能使用链路本地地址进行6LN到6LN通信。连接到同一个6LBR的6LN必须使用子网上使用的共享前缀相互通信。6LBR将一个6LN发送的数据包转发给另一个6LN。
At network interface initialization, both 6LN and 6LBR SHALL generate and assign IPv6 link-local addresses to the DECT ULE network interfaces [RFC4862] based on the DECT device addresses (see Section 2.3) that were used for establishing the underlying DECT ULE connection.
在网络接口初始化时，6LN和6LBR应根据用于建立基础DECT ULE连接的DECT设备地址（见第2.3节），生成IPv6链路本地地址并将其分配给DECT ULE网络接口[RFC4862]。
The DECT device addresses IPEI and RFPI MUST be used to derive the IPv6 link-local 64-bit Interface Identifiers (IIDs) for 6LN and 6LBR, respectively.
DECT设备地址IPEI和RFPI必须分别用于派生6LN和6LBR的IPv6链路本地64位接口标识符（IID）。
The rule for deriving IIDs from DECT device addresses is as follows: the DECT device addresses that consist of 40 bits each MUST be expanded with leading zero bits to form 48-bit intermediate addresses. The most significant bit in this newly formed 48-bit intermediate address is set to one for addresses derived from the RFPI and set to zero for addresses derived from the IPEI. 64-bit IIDs
从DECT设备地址派生IID的规则如下：每个由40位组成的DECT设备地址必须用前导零位展开，以形成48位中间地址。新形成的48位中间地址中的最高有效位对于从RFPI派生的地址设置为1，对于从IPEI派生的地址设置为0。64位IID
are derived from these intermediate 48-bit addresses following the guidance in Appendix A of [RFC4291]. However, because DECT and IEEE address spaces are different, this intermediate address cannot be considered to be unique within an IEEE address space. In the derived IIDs, the Universal/Local (U/L) bit (7th bit) will be zero, which indicates that derived IIDs are not 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; from IPEI=01.23.45.67.89, the derived IID is 00:01:23:ff:fe:45:67:89.
根据[RFC4291]附录A中的指南，从这些中间48位地址派生。但是，由于DECT和IEEE地址空间不同，因此不能认为该中间地址在IEEE地址空间中是唯一的。在派生IID中，通用/本地（U/L）位（第7位）将为零，这表示派生IID不是全局唯一的，请参见[RFC7136]。例如，从RFPI=11.22.33.44.55，导出的IID为80:11:22:ff:fe:33:44:55；根据IPEI=01.23.45.67.89，导出的IID为00:01:23:ff:fe:45:67:89。
Global uniqueness of an IID in link-local addresses is not required as they should never be leaked outside the subnet domain.
链路本地地址中IID的全局唯一性是不需要的，因为它们永远不会泄漏到子网域之外。
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.
如[RFC4291]中所定义，IPv6链路本地地址是通过将IID附加到前缀FE80:：/64来形成的，如图4所示。
10 bits 54 bits 64 bits
+----------+-----------------+----------------------+
|1111111010| zeros | Interface Identifier |
+----------+-----------------+----------------------+
10 bits 54 bits 64 bits
+----------+-----------------+----------------------+
|1111111010| zeros | Interface Identifier |
+----------+-----------------+----------------------+
Figure 4: IPv6 Link-Local Address in DECT ULE
图4：数据块中的IPv6链路本地地址
A 6LN MUST join the all-nodes multicast address.
6LN必须加入所有节点的多播地址。
After link-local address configuration, 6LN sends Router Solicitation messages as described in Section 6.3.7 of [RFC4861] and Section 5.3 of [RFC6775].
链路本地地址配置完成后，6LN发送[RFC4861]第6.3.7节和[RFC6775]第5.3节中所述的路由器请求消息。
For non-link-local addresses, 6LNs SHOULD NOT be configured to use IIDs derived from a MAC-48 device address or DECT device addresses. Alternative schemes such as Cryptographically Generated Addresses (CGAs) [RFC3972], privacy extensions [RFC4941], Hash-Based Addresses (HBAs) [RFC5535], DHCPv6 [RFC3315], or static, semantically opaque addresses [RFC7217] SHOULD be used by default. See also [RFC8065] for guidance of needed entropy in IIDs and the recommended lifetime of used IIDs. When generated IIDs are not globally unique, Duplicate Address Detection (DAD) [RFC4862] MUST be used. In situations where deployment constraints require the device's address to be embedded in the IID, the 6LN MAY form a 64-bit IID by utilizing the MAC-48 device address or DECT device addresses. The non-link-local addresses that a 6LN generates MUST be registered with 6LBR as described in Section 3.2.2.
对于非链路本地地址，不应将6LNs配置为使用从MAC-48设备地址或DECT设备地址派生的IID。默认情况下，应使用诸如加密生成地址（CGA）[RFC3972]、隐私扩展[RFC4941]、基于哈希的地址（HBA）[RFC5535]、DHCPv6[RFC3315]或静态、语义不透明地址[RFC7217]等替代方案。参见[RFC8065]了解IID中所需熵的指南和所用IID的建议寿命。当生成的IID不是全局唯一的时，必须使用重复地址检测（DAD）[RFC4862]。在部署限制要求将设备地址嵌入IID的情况下，6LN可通过利用MAC-48设备地址或DECT设备地址形成64位IID。如第3.2.2节所述，6LN生成的非链路本地地址必须在6LBR中注册。
The means for a 6LBR to obtain an IPv6 prefix for numbering the DECT ULE network is out of scope of this document, but a prefix can be, for example, assigned via DHCPv6 Prefix Delegation [RFC3633] or using IPv6 Unicast Unique Local Addresses (ULAs) [RFC4193]. Due to the
6LBR获取IPv6前缀以对DECT ULE网络进行编号的方法不在本文件的范围内，但前缀可通过DHCPv6前缀委派[RFC3633]或使用IPv6单播唯一本地地址（ULA）[RFC4193]进行分配。由于
link model of the DECT ULE, the 6LBR MUST set the "on-link" (L) flag to zero in the Prefix Information Option [RFC4861]. This will cause 6LNs to always send packets to the 6LBR, including the case when the destination is another 6LN using the same prefix.
对于DECT ULE的链路型号，6LBR必须在前缀信息选项[RFC4861]中将“链路上”（L）标志设置为零。这将导致6LNs始终向6LBR发送数据包，包括目的地是另一个使用相同前缀的6LN的情况。
"Neighbor Discovery Optimization for IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs)" [RFC6775] describes the Neighbor Discovery approach as adapted for use in several 6LoWPAN topologies, including the mesh topology. As DECT ULE does not support mesh networks, only those aspects of [RFC6775] that apply to star topology are considered.
“低功耗无线个人区域网络（6LoWPANs）上IPv6的邻居发现优化”[RFC6775]描述了适用于多种6LoWPAN拓扑（包括网状拓扑）的邻居发现方法。由于DECT ULE不支持网状网络，因此只考虑[RFC6775]中适用于星形拓扑的方面。
The following aspects of the Neighbor Discovery optimizations [RFC6775] are applicable to DECT ULE 6LNs:
邻居发现优化[RFC6775]的以下方面适用于DECT ULE 6LNs：
1. For sending Router Solicitations and processing Router Advertisements the DECT ULE 6LNs MUST, respectively, follow Sections 5.3 and 5.4 of the [RFC6775].
1. 对于发送路由器请求和处理路由器广告，第6条必须分别遵循[RFC6775]第5.3节和第5.4节的规定。
2. A DECT ULE 6LN MUST NOT register its link-local address. Because the IIDs used in link-local addresses are derived from DECT addresses, there will always exist a unique mapping between link-local and Layer 2 addresses.
2. DECT ULE 6LN不得注册其链路本地地址。由于链路本地地址中使用的IID来自DECT地址，因此链路本地地址和第2层地址之间始终存在唯一的映射。
3. A DECT ULE 6LN MUST register its non-link-local addresses with the 6LBR by sending a Neighbor Solicitation (NS) message with the Address Registration Option (ARO) and process the Neighbor Advertisement (NA) accordingly. The NS with the ARO option MUST be sent irrespective of the method used to generate the IID.
3. DECT ULE 6LN必须通过发送带有地址注册选项（ARO）的邻居请求（NS）消息，向6LBR注册其非链路本地地址，并相应地处理邻居公告（NA）。无论使用何种方法生成IID，都必须发送带有ARO选项的NS。
The DECT MAC layer broadcast service is considered inadequate for IP multicast because it does not support the MTU size required by IPv6.
DECT MAC层广播服务被认为不适合IP多播，因为它不支持IPv6所需的MTU大小。
Hence, traffic is always unicast between two DECT ULE nodes. Even in the case where a 6LBR is attached to multiple 6LNs, the 6LBR cannot do a multicast to all the connected 6LNs. If the 6LBR needs to send a multicast packet to all its 6LNs, it has to replicate the packet and unicast it on each link. However, this may not be energy efficient and particular care should be taken if the FP is battery-powered. To further conserve power, the 6LBR MUST keep track of multicast listeners at DECT ULE link-level granularity, and it MUST NOT forward multicast packets to 6LNs that have not registered for multicast groups the packets belong to. In the opposite direction, a 6LN can only transmit data to or through the 6LBR. Hence, when a 6LN
因此，流量总是在两个特定节点之间单播。即使6LBR连接到多个6LN，6LBR也无法对所有连接的6LN进行多播。如果6LBR需要向其所有6LN发送多播数据包，则必须复制该数据包并在每个链路上单播。但是，这可能不节能，如果FP由电池供电，则应特别小心。为了进一步节省电力，6LBR必须在DECT ULE链路级粒度上跟踪多播侦听器，并且不得将多播数据包转发给尚未注册数据包所属多播组的6LN。相反，6LN只能向或通过6LBR传输数据。因此，当一个6LN
needs to transmit an IPv6 multicast packet, the 6LN will unicast the corresponding DECT ULE packet to the 6LBR. The 6LBR will then forward the multicast packet to other 6LNs.
如果需要发送IPv6多播数据包，6LN将单播相应的数据包到6LBR。然后，6LBR将多播数据包转发给其他6LN。
As defined in [RFC6282], which specifies the compression format for IPv6 datagrams on top of IEEE 802.15.4, header compression is REQUIRED in this document as the basis for IPv6 header compression on top of DECT ULE. All headers MUST be compressed according to encoding formats as described in [RFC6282]. The DECT ULE's star topology structure, ARO and 6CO, can be exploited in order to provide a mechanism for address compression. The following text describes the principles of IPv6 address compression on top of DECT ULE.
[RFC6282]规定了IEEE 802.15.4之上IPv6数据报的压缩格式，如[RFC6282]中所定义，本文件中要求进行报头压缩，作为12条之上IPv6报头压缩的基础。必须根据[RFC6282]中所述的编码格式压缩所有标题。可以利用DECT ULE的星形拓扑结构ARO和6CO来提供地址压缩机制。下面的文本介绍了IPv6地址压缩的原理。
In a link-local communication terminated at 6LN and 6LBR, both the IPv6 source and destination addresses MUST be elided since the used IIDs map uniquely into the DECT link end-point addresses. A 6LN or 6LBR that receives a PDU containing an IPv6 packet can infer the corresponding IPv6 source address. For the unicast 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, and DAM=11.
在以6LN和6LBR终止的链路本地通信中，必须省略IPv6源地址和目标地址，因为使用的IID唯一地映射到DECT链路端点地址。接收包含IPv6数据包的PDU的6LN或6LBR可以推断相应的IPv6源地址。对于本段中考虑的单播通信类型，IPv6压缩头中必须使用以下设置：CID=0、SAC=0、SAM=11、DAC=0和DAM=11。
To enable efficient header compression, the 6LBR MUST include the 6LoWPAN Context Option (6CO) [RFC6775] for all prefixes the 6LBR advertises in Router Advertisements for use in stateless address autoconfiguration.
为了实现有效的报头压缩，6LBR必须包括6LoWPAN上下文选项（6CO）[RFC6775]，用于6LBR在路由器播发中播发的用于无状态地址自动配置的所有前缀。
When a 6LN transmits an IPv6 packet to a destination using global unicast IPv6 addresses, if a context is defined for the prefix of the 6LNs global IPv6 address, the 6LN MUST indicate this context in the corresponding source fields of the compressed IPv6 header as per Section 3.1 of [RFC6282] and MUST fully elide the latest registered IPv6 source address. For this, the 6LN MUST use the following settings in the IPv6 compressed header: CID=1, SAC=1, and SAM=11. In this case, the 6LBR can infer the elided IPv6 source address since 1) the 6LBR has previously assigned the prefix to the 6LNs and 2) the 6LBR maintains a Neighbor Cache that relates the device address and the IID of the corresponding PP. If a context is defined for the IPv6 destination address, the 6LN MUST also indicate this context in the corresponding destination fields of the compressed IPv6 header and MUST elide the prefix of the destination IPv6 address. For this, the 6LN MUST set the DAM field of the compressed IPv6 header as
当6LN使用全局单播IPv6地址将IPv6数据包传输到目的地时，如果为6LN全局IPv6地址的前缀定义了上下文，则6LN必须根据[RFC6282]第3.1节在压缩IPv6报头的相应源字段中指示该上下文并且必须完全删除最新注册的IPv6源地址。为此，6LN必须在IPv6压缩标题中使用以下设置：CID=1、SAC=1和SAM=11。在这种情况下，6LBR可以推断省略的IPv6源地址，因为1）6LBR之前已将前缀分配给6LNs，2）6LBR维护一个邻居缓存，该缓存将设备地址与相应PP的IID相关联。如果为IPv6目标地址定义了上下文，6LN还必须在压缩IPv6标头的相应目标字段中指示此上下文，并且必须省略目标IPv6地址的前缀。为此，6LN必须将压缩IPv6报头的DAM字段设置为
CID=1, DAC=1, and DAM=01 or DAM=11. Note that when a context is defined for the IPv6 destination address, the 6LBR can infer the elided destination prefix by using the context.
CID=1，DAC=1，DAM=01或DAM=11。请注意，当为IPv6目标地址定义上下文时，6LBR可以使用上下文推断省略的目标前缀。
When a 6LBR receives an IPv6 packet having a global unicast IPv6 address and the destination of the packet is a 6LN, if a context is defined for the prefix of the 6LN's global IPv6 address, the 6LBR MUST indicate this context in the corresponding destination fields of the compressed IPv6 header and MUST fully elide the IPv6 destination address of the packet if the destination address is the latest registered by the 6LN for the indicated context. For this, the 6LBR MUST set the DAM field of the IPv6 compressed header as DAM=11. CID and DAC MUST be set to CID=1 and DAC=1. If a context is defined for the prefix of the IPv6 source address, the 6LBR MUST indicate this context in the source fields of the compressed IPv6 header and MUST elide that prefix as well. For this, the 6LBR MUST set the SAM field of the IPv6 compressed header as CID=1, SAC=1, and SAM=01 or SAM=11.
当6LBR接收到具有全局单播IPv6地址的IPv6数据包且数据包的目的地为6LN时，如果为6LN的全局IPv6地址的前缀定义了上下文，6LBR必须在压缩IPv6报头的相应目标字段中指示此上下文，并且如果目标地址是6LN为指示上下文注册的最新地址，则必须完全删除数据包的IPv6目标地址。为此，6LBR必须将IPv6压缩头的DAM字段设置为DAM=11。CID和DAC必须设置为CID=1和DAC=1。如果为IPv6源地址的前缀定义了上下文，则6LBR必须在压缩IPv6标头的源字段中指示此上下文，并且必须删除该前缀。为此，6LBR必须将IPv6压缩头的SAM字段设置为CID=1、SAC=1和SAM=01或SAM=11。
In the DECT ULE star topology (see Section 2.2), each PP has a separate link to the FP, and the FP acts as an IPv6 router rather than a link layer switch. A Multi-Link Subnet model [RFC4903] has been chosen, specifically Non-Broadcast Multi-Access (NBMA) at Layer 2, as is further illustrated in Figure 5. The 6LBR forwards packets sent by one 6LN to another. In a typical scenario, the DECT ULE network is connected to the Internet as shown in the Figure 5. In this scenario, the DECT ULE network is deployed as one subnet using one /64 IPv6 prefix. The 6LBR acts as a router and forwards packets between 6LNs to and from Internet.
在DECT ULE星形拓扑（见第2.2节）中，每个PP都有一个到FP的单独链路，FP充当IPv6路由器而不是链路层交换机。选择了多链路子网模型[RFC4903]，特别是第2层的非广播多址（NBMA），如图5所示。6LBR将一个6LN发送的数据包转发给另一个6LN。在典型场景中，DECT ULE网络连接到Internet，如图5所示。在这种情况下，DECT ULE网络被部署为使用一个/64 IPv6前缀的一个子网。6LBR充当路由器，在6LNs和Internet之间转发数据包。
6LN
\ ____________
\ / \
6LN ---- 6LBR ------ | Internet |
/ \____________/
/
6LN
6LN
\ ____________
\ / \
6LN ---- 6LBR ------ | Internet |
/ \____________/
/
6LN
<-- One subnet -->
<-- DECT ULE -->
<-- One subnet -->
<-- DECT ULE -->
Figure 5: DECT ULE Network Connected to the Internet
图5：连接到Internet的数据块网络
In some scenarios, the DECT ULE network may transiently or permanently be an isolated network as shown in the Figure 6. In this case, the whole DECT ULE network consists of a single subnet with multiple links, where 6LBR is routing packets between 6LNs.
在某些情况下，DECT ULE网络可能暂时或永久为隔离网络，如图6所示。在这种情况下，整个DECT ULE网络由一个子网和多个链路组成，其中6LBR在6LN之间路由数据包。
6LN 6LN
\ /
\ /
6LN --- 6LBR --- 6LN
/ \
/ \
6LN 6LN
6LN 6LN
\ /
\ /
6LN --- 6LBR --- 6LN
/ \
/ \
6LN 6LN
<---- One subnet ---->
<------ DECT ULE ----->
<---- One subnet ---->
<------ DECT ULE ----->
Figure 6: Isolated DECT ULE Network
图6：隔离的DECT ULE网络
In the isolated network scenario, communications between 6LN and 6LBR can use IPv6 link-local methodology, but for communications between different PP, the FP has to act as 6LBR, number the network with a ULA prefix [RFC4193], and route packets between the PP.
在隔离网络场景中，6LN和6LBR之间的通信可以使用IPv6链路本地方法，但对于不同PP之间的通信，FP必须充当6LBR，使用ULA前缀[RFC4193]为网络编号，并在PP之间路由数据包。
In other more advanced systems scenarios with multiple FPs and 6LBR, each DECT ULE FP constitutes a wireless cell. The network can be configured as a Multi-Link Subnet in which the 6LN can operate within the same /64 subnet prefix in multiple cells as shown in the Figure 7. The FPs in such a scenario should behave as Backbone Routers (6BBR) as defined in [BACKBONE-ROUTER].
在具有多个FPs和6LBR的其他更高级系统场景中，每个数据块FP构成一个无线小区。该网络可配置为多链路子网，其中6LN可在多个单元中的相同/64子网前缀内运行，如图7所示。在这种情况下，FPs应表现为[主干路由器]中定义的主干路由器（6BBR）。
____________
/ \
| Internet |
\____________/
|
|
|
|
6BBR/ | 6BBR/
6LN ---- 6LBR -------+------- 6LBR ---- 6LN
/ \ / \
/ \ / \
6LN 6LN 6LN 6LN
____________
/ \
| Internet |
\____________/
|
|
|
|
6BBR/ | 6BBR/
6LN ---- 6LBR -------+------- 6LBR ---- 6LN
/ \ / \
/ \ / \
6LN 6LN 6LN 6LN
<------------------ One subnet ------------------>
<-- DECT ULE Cell --> <-- DECT ULE Cell -->
<------------------ One subnet ------------------>
<-- DECT ULE Cell --> <-- DECT ULE Cell -->
Figure 7: Multiple DECT ULE Cells in a Single Multi-link Subnet
图7：单个多链路子网中的多个数据块单元
This document does not require any IANA actions.
本文件不要求IANA采取任何行动。
The secure transmission of circuit mode services in DECT is based on the DSAA2 and DSC/DSC2 specifications developed by ETSI Technical Committee (TC) DECT and the ETSI Security Algorithms Group of Experts (SAGE).
DECT中电路模式服务的安全传输基于ETSI技术委员会（TC）DECT和ETSI安全算法专家组（SAGE）制定的DSAA2和DSC/DSC2规范。
DECT ULE communications are secured at the link layer (DLC) by encryption and per-message authentication through CCM (Counter with Cipher Block Chaining Message Authentication Code (CBC-MAC)) mode similar to [RFC3610]. The underlying algorithm for providing encryption and authentication is AES128.
通过类似于[RFC3610]的CCM（带有密码块链接消息认证码（CBC-MAC）的计数器）模式，通过加密和每消息认证在链路层（DLC）保护数据块通信。提供加密和身份验证的底层算法是AES128。
The DECT ULE pairing procedure generates a master User Authentication Key (UAK). During the location registration procedure, or when the permanent virtual circuits are established, the session security keys are generated. Both the master authentication key and session security keys are generated by use of the DSAA2 algorithm [EN300.175-part1-7], which uses AES128 as the underlying algorithm. Session security keys may be renewed regularly. The generated security keys (UAK and session security keys) are individual for each FP-PP binding; hence, all PPs in a system have different security keys. DECT ULE PPs do not use any shared encryption key.
DECT ULE配对过程生成主用户身份验证密钥（UAK）。在位置注册过程中，或在建立永久虚拟电路时，会生成会话安全密钥。主认证密钥和会话安全密钥都是通过使用DSAA2算法[EN300.175-part1-7]生成的，该算法使用AES128作为底层算法。会话安全密钥可以定期更新。生成的安全密钥（UAK和会话安全密钥）对于每个FP-PP绑定都是单独的；因此，系统中的所有PPs都有不同的安全密钥。DECT ULE PPs不使用任何共享加密密钥。
Even though DECT ULE offers link layer security, it is still recommended to use secure transport or application protocols above 6LoWPAN.
尽管DECT ULE提供了链路层安全性，但仍建议使用6LoWPAN以上的安全传输或应用程序协议。
From the privacy point of view, the IPv6 link-local address configuration described in Section 3.2.1 only reveals information about the 6LN to the 6LBR that the 6LBR already knows from the link layer connection. For non-link-local IPv6 addresses, by default, a 6LN SHOULD use a randomly generated IID, for example, as discussed in [RFC8064], or use alternative schemes such as Cryptographically Generated Addresses (CGAs) [RFC3972], privacy extensions [RFC4941], Hash-Based Addresses (HBAs, [RFC5535]), or static, semantically opaque addresses [RFC7217].
从隐私角度来看，第3.2.1节中描述的IPv6链路本地地址配置仅显示6LN到6LBR的信息，而6LBR已经从链路层连接中知道这些信息。对于非链路本地IPv6地址，默认情况下，6LN应使用随机生成的IID，例如，如[RFC8064]中所述，或使用替代方案，如加密生成地址（CGA）[RFC3972]、隐私扩展[RFC4941]、基于哈希的地址（HBA[RFC5535]）或静态、语义不透明的地址[RFC7217]。
ETSI is standardizing a list of known application-layer protocols that can use the DECT ULE permanent virtual circuit packet data service. Each protocol is identified by a unique known identifier, which is exchanged in the service-change procedure as defined in [TS102.939-1]. The IPv6/6LoWPAN as described in this document is considered to be an application-layer protocol on top of DECT ULE. In order to provide interoperability between 6LoWPAN / DECT ULE devices, a common protocol identifier for 6LoWPAN is standardized by ETSI.
ETSI正在标准化可使用DECT ULE永久虚拟电路分组数据服务的已知应用层协议列表。每个协议由唯一的已知标识符标识，该标识符在[TS102.939-1]中定义的服务变更程序中交换。本文档中所述的IPv6/6LoWPAN被视为DECT之上的应用层协议。为了提供6LoWPAN/DECT ULE设备之间的互操作性，ETSI对6LoWPAN的通用协议标识符进行了标准化。
The ETSI DECT ULE Application Protocol Identifier is set to 0x06 for 6LoWPAN [TS102.939-1].
对于6LoWPAN[TS102.939-1]，ETSI DECT ULE应用协议标识符设置为0x06。
[EN300.175-part1-7] ETSI, "Digital Enhanced Cordless Telecommunications (DECT); Common Interface (CI); Part 1: Overview", European Standard, ETSI EN 300 175-1, V2.6.1, July 2015, <https://www.etsi.org/deliver/ etsi_en/300100_300199/30017501/02.06.01_60/ en_30017501v020601p.pdf>.
[EN300.175-part1-7]ETSI，“数字增强无绳通信（DECT）；公共接口（CI）；第1部分：概述”，欧洲标准，ETSI EN 300 175-1，V2.6.11915年7月<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 Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，DOI 10.17487/RFC2119，1997年3月<http://www.rfc-editor.org/info/rfc2119>.
[RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic Host Configuration Protocol (DHCP) version 6", RFC 3633, DOI 10.17487/RFC3633, December 2003, <http://www.rfc-editor.org/info/rfc3633>.
[RFC3633]Troan，O.和R.Droms，“动态主机配置协议（DHCP）版本6的IPv6前缀选项”，RFC 3633，DOI 10.17487/RFC3633，2003年12月<http://www.rfc-editor.org/info/rfc3633>.
[RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast Addresses", RFC 4193, DOI 10.17487/RFC4193, October 2005, <http://www.rfc-editor.org/info/rfc4193>.
[RFC4193]Hinden，R.和B.Haberman，“唯一本地IPv6单播地址”，RFC 4193，DOI 10.17487/RFC4193，2005年10月<http://www.rfc-editor.org/info/rfc4193>.
[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 4291, DOI 10.17487/RFC4291, February 2006, <http://www.rfc-editor.org/info/rfc4291>.
[RFC4291]Hinden，R.和S.Deering，“IP版本6寻址体系结构”，RFC 4291，DOI 10.17487/RFC42912006年2月<http://www.rfc-editor.org/info/rfc4291>.
[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, DOI 10.17487/RFC4861, September 2007, <http://www.rfc-editor.org/info/rfc4861>.
[RFC4861]Narten，T.，Nordmark，E.，Simpson，W.，和H.Soliman，“IP版本6（IPv6）的邻居发现”，RFC 4861，DOI 10.17487/RFC48612007年9月<http://www.rfc-editor.org/info/rfc4861>.
[RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless Address Autoconfiguration", RFC 4862, DOI 10.17487/RFC4862, September 2007, <http://www.rfc-editor.org/info/rfc4862>.
[RFC4862]Thomson，S.，Narten，T.和T.Jinmei，“IPv6无状态地址自动配置”，RFC 4862，DOI 10.17487/RFC4862，2007年9月<http://www.rfc-editor.org/info/rfc4862>.
[RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy Extensions for Stateless Address Autoconfiguration in IPv6", RFC 4941, DOI 10.17487/RFC4941, September 2007, <http://www.rfc-editor.org/info/rfc4941>.
[RFC4941]Narten，T.，Draves，R.，和S.Krishnan，“IPv6中无状态地址自动配置的隐私扩展”，RFC 4941，DOI 10.17487/RFC49411907年9月<http://www.rfc-editor.org/info/rfc4941>.
[RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler, "Transmission of IPv6 Packets over IEEE 802.15.4 Networks", RFC 4944, DOI 10.17487/RFC4944, September 2007, <http://www.rfc-editor.org/info/rfc4944>.
[RFC4944]黑山，G.，Kushalnagar，N.，Hui，J.，和D.Culler，“通过IEEE 802.15.4网络传输IPv6数据包”，RFC 4944，DOI 10.17487/RFC4944，2007年9月<http://www.rfc-editor.org/info/rfc4944>.
[RFC6282] Hui, J., Ed. and P. Thubert, "Compression Format for IPv6 Datagrams over IEEE 802.15.4-Based Networks", RFC 6282, DOI 10.17487/RFC6282, September 2011, <http://www.rfc-editor.org/info/rfc6282>.
[RFC6282]Hui，J.，Ed.和P.Thubert，“基于IEEE 802.15.4的网络上IPv6数据报的压缩格式”，RFC 6282，DOI 10.17487/RFC6282，2011年9月<http://www.rfc-editor.org/info/rfc6282>.
[RFC6775] Shelby, Z., Ed., Chakrabarti, S., Nordmark, E., and C. Bormann, "Neighbor Discovery Optimization for IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs)", RFC 6775, DOI 10.17487/RFC6775, November 2012, <http://www.rfc-editor.org/info/rfc6775>.
[RFC6775]Shelby，Z.，Ed.，Chakrabarti，S.，Nordmark，E.，和C.Bormann，“低功率无线个人区域网络（6LoWPANs）上IPv6邻居发现优化”，RFC 6775，DOI 10.17487/RFC67752012年11月<http://www.rfc-editor.org/info/rfc6775>.
[RFC7136] Carpenter, B. and S. Jiang, "Significance of IPv6 Interface Identifiers", RFC 7136, DOI 10.17487/RFC7136, February 2014, <http://www.rfc-editor.org/info/rfc7136>.
[RFC7136]Carpenter，B.和S.Jiang，“IPv6接口标识符的重要性”，RFC 7136，DOI 10.17487/RFC7136，2014年2月<http://www.rfc-editor.org/info/rfc7136>.
[TS102.939-1] ETSI, "Digital Enhanced Cordless Telecommunications (DECT); Ultra Low Energy (ULE); Machine to Machine Communications; Part 1: Home Automation Network (phase 1)", Technical Specification, ETSI TS 102 939-1, V1.2.1, March 2015, <https://www.etsi.org/deliver/ etsi_ts/102900_102999/10293901/01.02.01_60/ ts_10293901v010201p.pdf>.
[TS102.939-1]ETSI，“数字增强无绳通信（DECT）；超低能耗（ULE）；机器对机器通信；第1部分：家庭自动化网络（第1阶段）”，技术规范，ETSI TS 102 939-1，V1.2.12015年3月<https://www.etsi.org/deliver/ etsi_ts/102900_102999/10293901/01.02.01_60/ts_10293901v010201p.pdf>。
[TS102.939-2] ETSI, "Digital Enhanced Cordless Telecommunications (DECT); Ultra Low Energy (ULE); Machine to Machine Communications; Part 2: Home Automation Network (phase 2)", Technical Specification, ETSI TS 102 939-2, V1.1.1, March 2015, <https://www.etsi.org/deliver/ etsi_ts/102900_102999/10293902/01.01.01_60/ ts_10293902v010101p.pdf>.
[TS102.939-2]ETSI，“数字增强无绳通信（DECT）；超低能耗（ULE）；机器对机器通信；第2部分：家庭自动化网络（第2阶段）”，技术规范，ETSI TS 102 939-2，V1.1.12015年3月<https://www.etsi.org/deliver/ etsi_ts/102900_102999/10293902/01.01.01_60/ts_10293902V01010101P.pdf>。
[BACKBONE-ROUTER] Thubert, P., "IPv6 Backbone Router", Work in Progress, draft-ietf-6lo-backbone-router-03, January 2017.
[主干网路由器]Thubert，P.，“IPv6主干网路由器”，正在进行中的工作，草案-ietf-6lo-BACKBONE-ROUTER-03，2017年1月。
[CAT-iq] DECT Forum, "CAT-iq at a Glance", January 2016, <http://www.dect.org/userfiles/Public/ DF_CAT-iq%20at%20a%20Glance.pdf>.
[CAT iq]DECT论坛，“CAT iq概览”，2016年1月<http://www.dect.org/userfiles/Public/ DF_CAT-iq%20at%20a%20Glance.pdf>。
[RFC3315] Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins, C., and M. Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3315, DOI 10.17487/RFC3315, July 2003, <http://www.rfc-editor.org/info/rfc3315>.
[RFC3315]Droms，R.，Ed.，Bound，J.，Volz，B.，Lemon，T.，Perkins，C.，和M.Carney，“IPv6的动态主机配置协议（DHCPv6）”，RFC 3315，DOI 10.17487/RFC3315，2003年7月<http://www.rfc-editor.org/info/rfc3315>.
[RFC3610] Whiting, D., Housley, R., and N. Ferguson, "Counter with CBC-MAC (CCM)", RFC 3610, DOI 10.17487/RFC3610, September 2003, <http://www.rfc-editor.org/info/rfc3610>.
[RFC3610]Whiting，D.，Housley，R.，和N.Ferguson，“CBC-MAC（CCM）计数器”，RFC 3610，DOI 10.17487/RFC3610，2003年9月<http://www.rfc-editor.org/info/rfc3610>.
[RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)", RFC 3972, DOI 10.17487/RFC3972, March 2005, <http://www.rfc-editor.org/info/rfc3972>.
[RFC3972]Aura，T.，“加密生成地址（CGA）”，RFC 3972，DOI 10.17487/RFC3972，2005年3月<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>.
[RFC4903]Thaler，D.，“多链路子网问题”，RFC 4903，DOI 10.17487/RFC4903，2007年6月<http://www.rfc-editor.org/info/rfc4903>.
[RFC5535] Bagnulo, M., "Hash-Based Addresses (HBA)", RFC 5535, DOI 10.17487/RFC5535, June 2009, <http://www.rfc-editor.org/info/rfc5535>.
[RFC5535]Bagnulo，M.，“基于哈希的地址（HBA）”，RFC 5535，DOI 10.17487/RFC55352009年6月<http://www.rfc-editor.org/info/rfc5535>.
[RFC7217] Gont, F., "A Method for Generating Semantically Opaque Interface Identifiers with IPv6 Stateless Address Autoconfiguration (SLAAC)", RFC 7217, DOI 10.17487/RFC7217, April 2014, <http://www.rfc-editor.org/info/rfc7217>.
[RFC7217]Gont，F.“使用IPv6无状态地址自动配置（SLAAC）生成语义不透明接口标识符的方法”，RFC 7217，DOI 10.17487/RFC72172014年4月<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>.
[RFC7668]Nieminen，J.，Savolainen，T.，Isomaki，M.，Patil，B.，Shelby，Z.，和C.Gomez，“蓝牙（R）低能量IPv6”，RFC 7668，DOI 10.17487/RFC7668，2015年10月<http://www.rfc-editor.org/info/rfc7668>.
[RFC8064] Gont, F., Cooper, A., Thaler, D., and W. Liu, "Recommendation on Stable IPv6 Interface Identifiers", RFC 8064, DOI 10.17487/RFC8064, February 2017, <http://www.rfc-editor.org/info/rfc8064>.
[RFC8064]Gont，F.，Cooper，A.，Thaler，D.，和W.Liu，“关于稳定IPv6接口标识符的建议”，RFC 8064，DOI 10.17487/RFC8064，2017年2月<http://www.rfc-editor.org/info/rfc8064>.
[RFC8065] Thaler, D., "Privacy Considerations for IPv6 Adaptation-Layer Mechanisms", RFC 8065, DOI 10.17487/RFC8065, February 2017, <http://www.rfc-editor.org/info/rfc8065>.
[RFC8065]Thaler，D.，“IPv6适配层机制的隐私考虑”，RFC 8065，DOI 10.17487/RFC8065，2017年2月<http://www.rfc-editor.org/info/rfc8065>.
Acknowledgements
致谢
We are grateful to the members of the IETF 6lo working group; this document borrows liberally from their work.
我们感谢IETF 6lo工作组的成员；这份文件大量借鉴了他们的工作。
Ralph Droms, Samita Chakrabarti, Kerry Lynn, Suresh Krishnan, Pascal Thubert, Tatuya Jinmei, Dale Worley, and Robert Sparks have provided valuable feedback for this document.
Ralph Droms、Samita Chakrabarti、Kerry Lynn、Suresh Krishnan、Pascal Thubert、Tatuya Jinmei、Dale Worley和Robert Sparks为本文件提供了宝贵的反馈。
Authors' Addresses
作者地址
Peter B. Mariager RTX A/S Stroemmen 6 DK-9400 Noerresundby Denmark
Peter B.Mariager RTX A/S Stroemen 6 DK-9400丹麦诺雷森德
Email: pm@rtx.dk
Email: pm@rtx.dk
Jens Toftgaard Petersen (editor) RTX A/S Stroemmen 6 DK-9400 Noerresundby Denmark
Jens Toftgard Petersen（编辑）RTX A/S Stromemen 6 DK-9400 Noerresundby丹麦
Email: jtp@rtx.dk
Email: jtp@rtx.dk
Zach Shelby ARM 150 Rose Orchard San Jose, CA 95134 United States of America
Zach Shelby ARM 150美国加利福尼亚州圣何塞玫瑰园95134
Email: zach.shelby@arm.com
Email: zach.shelby@arm.com
Marco van de Logt Bosch Sensortec GmbH Gerhard-Kindler-Str. 9 72770 Reutlingen Germany
德国鲁特林根Gerhard-Kindler-Str.9 72770 Marco van de Logt Bosch Sensortec GmbH
Email: marco.vandelogt@bosch-sensortec.com
Email: marco.vandelogt@bosch-sensortec.com
Dominique Barthel Orange Labs 28 chemin du Vieux Chene 38243 Meylan France
Dominique Barthel Orange Labs 28 chemin du Vieux Chene 38243 Meylan France
Email: dominique.barthel@orange.com
Email: dominique.barthel@orange.com