Internet Engineering Task Force (IETF) J. Nieminen
Request for Comments: 7668 TeliaSonera
Category: Standards Track T. Savolainen
ISSN: 2070-1721 M. Isomaki
Nokia
B. Patil
AT&T
Z. Shelby
ARM
C. Gomez
Universitat Politecnica de Catalunya/i2CAT
October 2015
Internet Engineering Task Force (IETF) J. Nieminen
Request for Comments: 7668 TeliaSonera
Category: Standards Track T. Savolainen
ISSN: 2070-1721 M. Isomaki
Nokia
B. Patil
AT&T
Z. Shelby
ARM
C. Gomez
Universitat Politecnica de Catalunya/i2CAT
October 2015
IPv6 over BLUETOOTH(R) Low Energy
蓝牙IPv6（R）低能耗
Abstract
摘要
Bluetooth Smart is the brand name for the Bluetooth low energy feature in the Bluetooth specification defined by the Bluetooth Special Interest Group. The standard Bluetooth radio has been widely implemented and available in mobile phones, notebook computers, audio headsets, and many other devices. The low-power version of Bluetooth is a specification that enables the use of this air interface with devices such as sensors, smart meters, appliances, etc. The low-power variant of Bluetooth has been standardized since revision 4.0 of the Bluetooth specifications, although version 4.1 or newer is required for IPv6. This document describes how IPv6 is transported over Bluetooth low energy using IPv6 over Low-power Wireless Personal Area Network (6LoWPAN) techniques.
Bluetooth Smart是Bluetooth Special Interest Group定义的Bluetooth规范中的Bluetooth low energy功能的品牌名称。标准蓝牙收音机已广泛应用于移动电话、笔记本电脑、音频耳机和许多其他设备中。蓝牙的低功耗版本是一种规范，允许将此空中接口与传感器、智能仪表、电器等设备一起使用。自蓝牙规范的第4.0版以来，蓝牙的低功耗变体已经标准化，尽管IPv6需要4.1或更高版本。本文档介绍如何使用IPv6 over low-power Wireless Personal Area Network（6LoWPAN）技术通过蓝牙低能耗传输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 5741.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。有关互联网标准的更多信息，请参见RFC 5741第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/rfc7668.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc7668.
Copyright Notice
版权公告
Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2015 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 ...................................................3
1.1. Terminology and Requirements Language .......................3
2. Bluetooth Low Energy ...........................................4
2.1. Bluetooth LE Stack .........................................4
2.2. Roles and Topology for Link Layer ...........................5
2.3. Bluetooth LE Device Addressing .............................6
2.4. Bluetooth LE Packet Sizes and MTU ...........................6
3. Specification of IPv6 over Bluetooth Low Energy .................7
3.1. Protocol Stack .............................................8
3.2. Link Model .................................................8
3.2.1. IPv6 Subnet Model and Internet Connectivity .........9
3.2.2. Stateless Address Autoconfiguration ................10
3.2.3. Neighbor Discovery .................................12
3.2.4. Header Compression .................................13
3.2.4.1. Remote Destination Example ................14
3.2.4.2. Example of Registration of
Multiple Addresses ........................15
3.2.5. Unicast and Multicast Address Mapping ..............16
4. Security Considerations ........................................16
5. References .....................................................17
5.1. Normative References ......................................17
5.2. Informative References ....................................18
Acknowledgements ..................................................20
Contributors ......................................................20
Authors' Addresses ................................................20
1. Introduction ...................................................3
1.1. Terminology and Requirements Language .......................3
2. Bluetooth Low Energy ...........................................4
2.1. Bluetooth LE Stack .........................................4
2.2. Roles and Topology for Link Layer ...........................5
2.3. Bluetooth LE Device Addressing .............................6
2.4. Bluetooth LE Packet Sizes and MTU ...........................6
3. Specification of IPv6 over Bluetooth Low Energy .................7
3.1. Protocol Stack .............................................8
3.2. Link Model .................................................8
3.2.1. IPv6 Subnet Model and Internet Connectivity .........9
3.2.2. Stateless Address Autoconfiguration ................10
3.2.3. Neighbor Discovery .................................12
3.2.4. Header Compression .................................13
3.2.4.1. Remote Destination Example ................14
3.2.4.2. Example of Registration of
Multiple Addresses ........................15
3.2.5. Unicast and Multicast Address Mapping ..............16
4. Security Considerations ........................................16
5. References .....................................................17
5.1. Normative References ......................................17
5.2. Informative References ....................................18
Acknowledgements ..................................................20
Contributors ......................................................20
Authors' Addresses ................................................20
Bluetooth Smart is the brand name for the Bluetooth low energy feature (hereinafter, "Bluetooth LE") in the Bluetooth specification defined by the Bluetooth Special Interest Group [BTCorev4.1]. Bluetooth LE is a radio technology targeted for devices that operate with very low-capacity (e.g., coin cell) batteries or minimalistic power sources, which means that low power consumption is essential. Bluetooth LE is an especially attractive technology for Internet of Things applications, such as health monitors, environmental sensing, proximity applications, and many others.
Bluetooth Smart是Bluetooth Special Interest Group[BTCorev4.1]定义的蓝牙规范中的蓝牙低能量功能（以下简称“蓝牙LE”）的品牌名称。蓝牙LE是一种无线电技术，适用于使用极低容量（如币形电池）电池或最低限度电源工作的设备，这意味着低功耗至关重要。蓝牙LE是物联网应用的一项特别有吸引力的技术，如健康监测器、环境传感、近距离应用等。
Considering the potential for the exponential growth in the number of sensors and Internet connected devices, IPv6 is an ideal protocol for communication with such devices due to the large address space it provides. In addition, IPv6 provides tools for stateless address autoconfiguration, which is particularly suitable for sensor network applications and nodes that have very limited processing power or lack a full-fledged operating system or a user interface.
考虑到传感器和互联网连接设备数量可能呈指数级增长，IPv6提供了巨大的地址空间，是与此类设备通信的理想协议。此外，IPv6为无状态地址自动配置提供了工具，特别适用于处理能力非常有限或缺乏完整操作系统或用户界面的传感器网络应用程序和节点。
This document describes how IPv6 is transported over Bluetooth LE connections using IPv6 over Low-power Wireless Personal Area Network (6LoWPAN) techniques. RFCs 4944 [RFC4944], 6282 [RFC6282], and 6775 [RFC6775] were developed for 6LoWPAN and specify the transmission of IPv6 over IEEE 802.15.4 [IEEE802.15.4]. The Bluetooth LE link, in many respects, has similar characteristics to that of IEEE 802.15.4, and many of the mechanisms defined for IPv6 over IEEE 802.15.4 can be applied to the transmission of IPv6 on Bluetooth LE links. This document specifies the details of IPv6 transmission over Bluetooth LE links.
本文档描述了如何使用低功耗无线个人区域网（6LoWPAN）技术通过蓝牙LE连接传输IPv6。RFC 4944[RFC4944]、6282[RFC6282]和6775[RFC6775]是为6LoWPAN开发的，并规定了IPv6在IEEE 802.15.4[IEEE802.15.4]上的传输。蓝牙LE链路在许多方面具有与IEEE 802.15.4相似的特性，并且为IEEE 802.15.4上的IPv6定义的许多机制可应用于蓝牙LE链路上的IPv6传输。本文档规定了通过蓝牙LE链路进行IPv6传输的详细信息。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC 2119[RFC2119]中所述进行解释。
The terms "6LoWPAN Node (6LN)", "6LoWPAN Router (6LR)", and "6LoWPAN Border Router (6LBR)" are defined as in [RFC6775], with an addition that Bluetooth LE central and Bluetooth LE peripheral (see Section 2.2) can both be either 6LN or 6LBR.
术语“6LoWPAN节点（6LN）”、“6LoWPAN路由器（6LR）”和“6LoWPAN边界路由器（6LBR）”的定义如[RFC6775]所述，此外，蓝牙LE中央和蓝牙LE外围设备（参见第2.2节）可以是6LN或6LBR。
The acronyms "DAC", "DAM", "SAC", "SAM", and "CID" are used in this document as defined in [RFC6282]. They are expanded as follows:
本文件中使用了[RFC6282]中定义的首字母缩略词“DAC”、“DAM”、“SAC”、“SAM”和“CID”。它们的扩展如下：
o Destination Address Compression (DAC)
o 目标地址压缩（DAC）
o Destination Address Mode (DAM)
o 目标地址模式（DAM）
o Source Address Compression (SAC)
o 源地址压缩（SAC）
o Source Address Mode (SAM)
o 源地址模式（SAM）
o Context Identifier (CID)
o 上下文标识符（CID）
Bluetooth LE is designed for transferring small amounts of data infrequently at modest data rates with a very small energy expenditure per bit. The Bluetooth Special Interest Group (Bluetooth SIG) has introduced two trademarks: Bluetooth Smart for single-mode devices (a device that only supports Bluetooth LE) and Bluetooth Smart Ready for dual-mode devices (devices that support both Bluetooth and Bluetooth LE; note that Bluetooth and Bluetooth LE are different, non-interoperable radio technologies). In the rest of this document, the term "Bluetooth LE" is used regardless of whether this technology is supported by a single-mode or dual-mode device.
蓝牙LE设计用于以适中的数据速率传输少量数据，每比特的能量消耗非常小。Bluetooth特殊利益集团（Bluetooth SIG）推出了两个商标：适用于单模设备的Bluetooth Smart（仅支持Bluetooth LE的设备）和适用于双模设备的Bluetooth Smart Ready（同时支持蓝牙和蓝牙LE的设备；请注意，蓝牙和蓝牙LE是不同的、不可互操作的无线电技术）。在本文档的其余部分中，使用术语“蓝牙LE”，无论该技术是由单模还是双模设备支持。
Bluetooth LE was introduced in Bluetooth 4.0, enhanced in Bluetooth 4.1 [BTCorev4.1], and developed even further in successive versions. Bluetooth SIG has also published the Internet Protocol Support Profile (IPSP) [IPSP], which includes the Internet Protocol Support Service (IPSS). The IPSP enables discovery of IP-enabled devices and establishment of a link-layer connection for transporting IPv6 packets. IPv6 over Bluetooth LE is dependent on both Bluetooth 4.1 and IPSP 1.0 or more recent versions of either specification to provide necessary capabilities.
Bluetooth LE在Bluetooth 4.0中引入，在Bluetooth 4.1[BTCorev4.1]中增强，并在后续版本中进一步发展。Bluetooth SIG还发布了互联网协议支持配置文件（IPSP）[IPSP]，其中包括互联网协议支持服务（IPSS）。IPSP能够发现启用IP的设备，并建立用于传输IPv6数据包的链路层连接。蓝牙上的IPv6 LE同时依赖于Bluetooth 4.1和IPSP 1.0或更高版本的两种规范，以提供必要的功能。
Devices such as mobile phones, notebooks, tablets, smartwatches, and other handheld computing devices that incorporate chipsets implementing Bluetooth 4.1 or later will also have the low energy functionality of Bluetooth. Bluetooth LE is also expected to be included in many different types of accessories that collaborate with mobile devices such as phones, tablets, and notebook computers. An example of a use case for a Bluetooth LE accessory is a heart rate monitor that sends data via a mobile phone or smartwatch to a server on the Internet or sends data directly to the device.
手机、笔记本电脑、平板电脑、智能手表和其他手持计算设备（包括采用蓝牙4.1或更高版本的芯片组）等设备也将具有蓝牙的低能耗功能。蓝牙LE预计还将包含在与手机、平板电脑和笔记本电脑等移动设备协作的许多不同类型的配件中。蓝牙LE附件的一个用例示例是心率监视器，它通过移动电话或smartwatch向Internet上的服务器发送数据，或直接向设备发送数据。
The lower layer of the Bluetooth LE stack consists of the Physical Layer (PHY), the Link Layer (LL), and a test interface called the Direct Test Mode (DTM). The Physical Layer transmits and receives the actual packets. The Link Layer is responsible for providing medium access, connection establishment, error control, and flow control. The Direct Test Mode is only used for testing purposes. The upper layer consists of the Logical Link Control and Adaptation
蓝牙LE堆栈的较低层由物理层（PHY）、链路层（LL）和称为直接测试模式（DTM）的测试接口组成。物理层发送和接收实际数据包。链路层负责提供介质访问、连接建立、错误控制和流控制。直接测试模式仅用于测试目的。上层由逻辑链路控制和自适应组成
Protocol (L2CAP), Attribute Protocol (ATT), Security Manager (SM), Generic Attribute Profile (GATT), and Generic Access Profile (GAP) as shown in Figure 1. The Host Controller Interface (HCI) separates the lower layers, often implemented in the Bluetooth controller, from higher layers, often implemented in the host stack. GATT and Bluetooth LE profiles together enable the creation of applications in a standardized way without using IP. L2CAP provides multiplexing capability by multiplexing the data channels from the above layers. L2CAP also provides fragmentation and reassembly for large data packets. The Security Manager defines a protocol and mechanisms for pairing, key distribution, and a security toolbox for the Bluetooth LE device.
协议（L2CAP）、属性协议（ATT）、安全管理器（SM）、通用属性配置文件（GATT）和通用访问配置文件（GAP），如图1所示。主机控制器接口（HCI）将通常在蓝牙控制器中实现的较低层与通常在主机堆栈中实现的较高层分开。GATT和蓝牙LE配置文件共同支持以标准化方式创建应用程序，而无需使用IP。L2CAP通过复用来自上述层的数据信道来提供复用能力。L2CAP还为大数据包提供碎片和重组。Security Manager为蓝牙设备定义了配对、密钥分发和安全工具箱的协议和机制。
+-------------------------------------------------+
| Applications |
+---------------------------------------+---------+
| Generic Attribute Profile | Generic |
+--------------------+------------------+ Access |
| Attribute Protocol | Security Manager | Profile |
+--------------------+------------------+---------+
| Logical Link Control and Adaptation Protocol |
- - -+-----------------------+-------------------------+- - - HCI
| Link Layer | Direct Test Mode |
+-------------------------------------------------+
| Physical Layer |
+-------------------------------------------------+
+-------------------------------------------------+
| Applications |
+---------------------------------------+---------+
| Generic Attribute Profile | Generic |
+--------------------+------------------+ Access |
| Attribute Protocol | Security Manager | Profile |
+--------------------+------------------+---------+
| Logical Link Control and Adaptation Protocol |
- - -+-----------------------+-------------------------+- - - HCI
| Link Layer | Direct Test Mode |
+-------------------------------------------------+
| Physical Layer |
+-------------------------------------------------+
Figure 1: Bluetooth LE Protocol Stack
图1：蓝牙LE协议栈
As shown in Section 3.1, IPv6 over Bluetooth LE requires an adapted 6LoWPAN layer that runs on top of Bluetooth LE L2CAP.
如第3.1节所示，蓝牙LE上的IPv6需要在蓝牙LE L2CAP上运行一个经过调整的6LoWPAN层。
Bluetooth LE defines two GAP roles of relevance herein: the Bluetooth LE central role and the Bluetooth LE peripheral role. A device in the central role (called "central" from now on) has traditionally been able to manage multiple simultaneous connections with a number of devices in the peripheral role (called "peripherals" from now on). A peripheral is commonly connected to a single central, but with versions of Bluetooth from 4.1 onwards, it can also connect to multiple centrals at the same time. In this document, for IPv6 networking purposes, the Bluetooth LE network (i.e., a Bluetooth LE piconet) follows a star topology shown in the Figure 2, where a router typically implements the Bluetooth LE central role and the rest of nodes implement the Bluetooth LE peripheral role. In the future, mesh networking and/or parallel connectivity to multiple centrals at a time may be defined for IPv6 over Bluetooth LE.
蓝牙LE在此定义了两个相关的GAP角色：蓝牙LE中心角色和蓝牙LE外围角色。处于中心角色的设备（从现在起称为“中心”）传统上能够管理与处于外围角色的多个设备（从现在起称为“外围设备”）的多个同时连接。外围设备通常连接到一个中央设备，但从4.1版开始的蓝牙版本也可以同时连接到多个中央设备。在本文档中，出于IPv6联网目的，蓝牙LE网络（即蓝牙LE微微网）遵循图2中所示的星形拓扑，其中路由器通常实现蓝牙LE中心角色，其余节点实现蓝牙LE外围角色。将来，可以为通过蓝牙的IPv6定义一次到多个中心的网状网络和/或并行连接。
Peripheral --. .-- Peripheral
\ /
Peripheral ---- Central ---- Peripheral
/ \
Peripheral --' '-- Peripheral
Peripheral --. .-- Peripheral
\ /
Peripheral ---- Central ---- Peripheral
/ \
Peripheral --' '-- Peripheral
Figure 2: Bluetooth LE Star Topology
图2：蓝牙LE星形拓扑
In Bluetooth LE, direct wireless communication only takes place between a central and a peripheral. This means that inherently the Bluetooth LE star represents a hub-and-spokes link model. Nevertheless, two peripherals may communicate through the central by using IP routing functionality per this specification.
在蓝牙LE中，直接无线通信仅发生在中央和外围设备之间。这意味着蓝牙LE-star本质上代表了一种集线器和辐条链接模型。然而，根据本规范，两个外围设备可以通过使用IP路由功能通过中心进行通信。
Every Bluetooth LE device is identified by a 48-bit device address. The Bluetooth specification [BTCorev4.1] describes the device address of a Bluetooth LE device as follows: "Devices are identified using a device address. Device addresses may be either a public device address or a random device address". The public device addresses are based on the IEEE 802 standard [IEEE802]. Random device addresses and the Bluetooth LE privacy feature are described in the Bluetooth Generic Access Profile, Sections 10.8 and 10.7 of [BTCorev4.1], respectively. There are two types of random device addresses: static and private addresses. The private addresses are further divided into two sub-types: resolvable or non-resolvable addresses, which are explained in depth in the referenced Bluetooth specification. Once a static address is initialized, it does not change until the device is power cycled. The static address can be initialized to a new value after each power cycle, but that is not mandatory. The recommended time interval before randomizing new private address is 15 minutes, as determined by timer T_GAP(private_addr_int) in Table 17.1 of the Bluetooth Generic Access Profile [BTCorev4.1]. The selection of which device address types are used is implementation and deployment specific. In random addresses, the first 46 bits are randomized, and the last 2 bits indicate the random address type. Bluetooth LE does not support avoidance or detection of device address collisions. However, these 48-bit random device addresses have a very small probability of being in conflict within a typical deployment.
每个蓝牙LE设备都由48位设备地址标识。蓝牙规范[BTCorev4.1]将蓝牙LE设备的设备地址描述为：“使用设备地址识别设备。设备地址可以是公共设备地址或随机设备地址”。公共设备地址基于IEEE 802标准[IEEE802]。随机设备地址和蓝牙LE隐私功能分别在[BTCorev4.1]第10.8节和第10.7节的蓝牙通用访问配置文件中进行了描述。有两种类型的随机设备地址：静态地址和专用地址。专用地址进一步分为两个子类型：可解析地址或不可解析地址，在参考的蓝牙规范中对此进行了深入解释。静态地址初始化后，在设备断电之前不会更改。静态地址可以在每次电源循环后初始化为新值，但这不是强制性的。根据蓝牙通用访问配置文件[BTCorev4.1]表17.1中的计时器T_GAP（private_addr_int）确定，随机分配新专用地址之前的建议时间间隔为15分钟。所使用的设备地址类型的选择取决于实现和部署。在随机地址中，前46位是随机的，后2位表示随机地址类型。蓝牙LE不支持避免或检测设备地址冲突。然而，在典型部署中，这些48位随机设备地址发生冲突的可能性很小。
The optimal MTU defined for L2CAP fixed channels over Bluetooth LE is 27 octets, including the L2CAP header of 4 octets. The default MTU for Bluetooth LE is hence defined to be 27 octets. Therefore, excluding the L2CAP header of 4 octets, a protocol data unit (PDU) size of 23 octets is available for upper layers. In order to be able
通过蓝牙LE为L2CAP固定信道定义的最佳MTU为27个八位字节，包括4个八位字节的L2CAP头。因此，蓝牙LE的默认MTU定义为27个八位字节。因此，除去4个八位字节的L2CAP头，上层可用的协议数据单元（PDU）大小为23个八位字节。为了能够
to transmit IPv6 packets of 1280 octets or larger, a link-layer fragmentation and reassembly solution is provided by the L2CAP layer. The IPSP defines means for negotiating up a link-layer connection that provides an MTU of 1280 octets or higher for the IPv6 layer [IPSP]. The link-layer MTU is negotiated separately for each direction. Implementations that require an equal link-layer MTU for the two directions SHALL use the smallest of the possibly different MTU values.
为了传输1280个八位字节或更大的IPv6数据包，L2CAP层提供了链路层碎片和重组解决方案。IPSP定义了协商链路层连接的方法，该连接为IPv6层[IPSP]提供1280个八位字节或更高的MTU。链路层MTU针对每个方向单独协商。要求两个方向的链路层MTU相等的实现应使用可能不同的MTU值中的最小值。
Bluetooth LE technology sets strict requirements for low power consumption and thus limits the allowed protocol overhead. 6LoWPAN standards [RFC6775] [RFC6282] provide useful functionality for reducing overhead, which is applied to Bluetooth LE. This functionality is comprised of link-local IPv6 addresses and stateless IPv6 address autoconfiguration (see Section 3.2.2), Neighbor Discovery (see Section 3.2.3), and header compression (see Section 3.2.4). Fragmentation features from 6LoWPAN standards are not used due to Bluetooth LE's link-layer fragmentation support (see Section 2.4).
蓝牙LE技术对低功耗提出了严格要求，从而限制了允许的协议开销。6LoWPAN标准[RFC6775][RFC6282]为减少开销提供了有用的功能，适用于蓝牙LE。此功能包括链路本地IPv6地址和无状态IPv6地址自动配置（见第3.2.2节）、邻居发现（见第3.2.3节）和报头压缩（见第3.2.4节）。由于蓝牙LE的链路层分段支持（参见第2.4节），因此未使用6LoWPAN标准中的分段功能。
A significant difference between IEEE 802.15.4 and Bluetooth LE is that the former supports both star and mesh topologies (and requires a routing protocol), whereas Bluetooth LE does not currently support the formation of multihop networks at the link layer. However, inter-peripheral communication through the central is enabled by using IP routing functionality per this specification.
IEEE 802.15.4和蓝牙LE之间的一个显著区别是前者支持星形和网状拓扑（并且需要路由协议），而蓝牙LE目前不支持在链路层形成多跳网络。但是，根据本规范，通过使用IP路由功能，可以通过中央设备实现外围设备间通信。
In Bluetooth LE, a central node is assumed to be less resource constrained than a peripheral node. Hence, in the primary deployment scenario, central and peripheral will act as 6LoWPAN Border Router (6LBR) and a 6LoWPAN Node (6LN), respectively.
在蓝牙LE中，假设中心节点比外围节点受到更少的资源约束。因此，在主要部署场景中，中央和外围将分别充当6LoWPAN边界路由器（6LBR）和6LoWPAN节点（6LN）。
Before any IP-layer communications can take place over Bluetooth LE, nodes enabled by Bluetooth LE such as 6LNs and 6LBRs have to find each other and establish a suitable link-layer connection. The discovery and Bluetooth LE connection setup procedures are documented by the Bluetooth SIG in the IPSP specification [IPSP].
在通过蓝牙LE进行任何IP层通信之前，由蓝牙LE启用的节点（如6LNs和6LBRs）必须找到彼此并建立适当的链路层连接。发现和蓝牙LE连接设置程序由蓝牙SIG在IPSP规范[IPSP]中记录。
In the rare case of Bluetooth LE random device address conflict, a 6LBR can detect multiple 6LNs with the same Bluetooth LE device address, as well as a 6LN with the same Bluetooth LE address as the 6LBR. The 6LBR MUST ignore 6LNs with the same device address the 6LBR has, and the 6LBR MUST have at most one connection for a given Bluetooth LE device address at any given moment. This will avoid addressing conflicts within a Bluetooth LE network.
在罕见的蓝牙LE随机设备地址冲突情况下，6LBR可以检测到具有相同蓝牙LE设备地址的多个6LN，以及具有与6LBR相同蓝牙LE地址的6LN。6LBR必须忽略6LBR具有相同设备地址的6LNs，并且6LBR必须在任何给定时刻最多有一个连接用于给定的蓝牙LE设备地址。这将避免在蓝牙LE网络中解决冲突。
Figure 3 illustrates how the IPv6 stack works in parallel to the GATT stack on top of the Bluetooth LE L2CAP layer. The GATT stack is needed herein for discovering nodes supporting the Internet Protocol Support Service. UDP and TCP are provided as examples of transport protocols, but the stack can be used by any other upper-layer protocol capable of running atop of IPv6.
图3说明了IPv6堆栈如何与蓝牙LE L2CAP层顶部的GATT堆栈并行工作。这里需要GATT栈来发现支持因特网协议支持服务的节点。UDP和TCP是作为传输协议的示例提供的，但是该协议栈可以由能够在IPv6上运行的任何其他上层协议使用。
+---------+ +----------------------------+
| IPSS | | UDP/TCP/other |
+---------+ +----------------------------+
| GATT | | IPv6 |
+---------+ +----------------------------+
| ATT | | 6LoWPAN for Bluetooth LE |
+---------+--+----------------------------+
| Bluetooth LE L2CAP |
- - +-----------------------------------------+- - - HCI
| Bluetooth LE Link Layer |
+-----------------------------------------+
| Bluetooth LE Physical |
+-----------------------------------------+
+---------+ +----------------------------+
| IPSS | | UDP/TCP/other |
+---------+ +----------------------------+
| GATT | | IPv6 |
+---------+ +----------------------------+
| ATT | | 6LoWPAN for Bluetooth LE |
+---------+--+----------------------------+
| Bluetooth LE L2CAP |
- - +-----------------------------------------+- - - HCI
| Bluetooth LE Link Layer |
+-----------------------------------------+
| Bluetooth LE Physical |
+-----------------------------------------+
Figure 3: IPv6 and IPSS on the Bluetooth LE Stack
图3：蓝牙LE协议栈上的IPv6和IPSS
The distinct concepts of the IPv6 link (layer 3) and the physical link (combination of PHY and Media Access Control (MAC)) need to be clear, and their relationship has to be well understood in order to specify the addressing scheme for transmitting IPv6 packets over the Bluetooth LE link. RFC 4861 [RFC4861] defines a link as "a communication facility or medium over which nodes can communicate at the link layer, i.e., the layer immediately below IP".
IPv6链路（第3层）和物理链路（PHY和媒体访问控制（MAC）的组合）的不同概念需要明确，并且必须很好地理解它们之间的关系，以便指定通过蓝牙LE链路传输IPv6数据包的寻址方案。RFC 4861[RFC4861]将链路定义为“一种通信设施或介质，节点可通过该通信设施或介质在链路层（即IP正下方的层）进行通信”。
In the case of Bluetooth LE, the 6LoWPAN layer is adapted to support transmission of IPv6 packets over Bluetooth LE. The IPSP defines all steps required for setting up the Bluetooth LE connection over which 6LoWPAN can function [IPSP], including handling the link-layer fragmentation required on Bluetooth LE, as described in Section 2.4. Even though MTUs larger than 1280 octets can be supported, use of a 1280-octet MTU is RECOMMENDED in order to avoid need for Path MTU discovery procedures.
在蓝牙LE的情况下，6LoWPAN层适于支持通过蓝牙LE传输IPv6分组。IPSP定义了设置蓝牙LE连接所需的所有步骤，6LoWPAN可在该连接上运行[IPSP]，包括处理蓝牙LE所需的链路层碎片，如第2.4节所述。尽管可以支持大于1280个八位字节的MTU，但建议使用1280个八位字节的MTU，以避免需要路径MTU发现过程。
While Bluetooth LE protocols, such as L2CAP, utilize little-endian byte ordering, IPv6 packets MUST be transmitted in big-endian order (network byte order).
虽然蓝牙LE协议（如L2CAP）利用小端字节顺序，但IPv6数据包必须以大端顺序（网络字节顺序）传输。
Per this specification, the IPv6 header compression format specified in RFC 6282 [RFC6282] MUST be used. The IPv6 payload length can be derived from the L2CAP header length and the possibly elided IPv6 address can be reconstructed from the link-layer address, used at the time of Bluetooth LE connection establishment, from the HCI Connection Handle during connection, compression context if any, and address registration information (see Section 3.2.3).
根据本规范，必须使用RFC 6282[RFC6282]中指定的IPv6标头压缩格式。IPv6有效负载长度可以从L2CAP报头长度中导出，并且可能省略的IPv6地址可以从建立蓝牙LE连接时使用的链路层地址、连接期间的HCI连接句柄、压缩上下文（如果有）和地址注册信息中重构（见第3.2.3节）。
Bluetooth LE connections used to build a star topology are point-to-point in nature, as Bluetooth broadcast features are not used for IPv6 over Bluetooth LE (except for discovery of nodes supporting IPSS). After the peripheral and central have connected at the Bluetooth LE level, the link can be considered up, and IPv6 address configuration and transmission can begin.
用于构建星形拓扑的蓝牙LE连接本质上是点对点连接，因为蓝牙广播功能不用于通过蓝牙LE的IPv6（支持IPSS的节点发现除外）。在外围设备和中央设备在蓝牙LE级别连接后，可以考虑连接，并且可以开始IPv6地址配置和传输。
In the Bluetooth LE piconet model (see Section 2.2), peripherals each have a separate link to the central and the central acts as an IPv6 router rather than a link-layer switch. As discussed in [RFC4903], conventional usage of IPv6 anticipates IPv6 subnets spanning a single link at the link layer. As IPv6 over Bluetooth LE is intended for constrained nodes, and for Internet of Things use cases and environments, the complexity of implementing a separate subnet on each peripheral-central link and routing between the subnets appears to be excessive. In the Bluetooth LE case, the benefits of treating the collection of point-to-point links between a central and its connected peripherals as a single multilink subnet rather than a multiplicity of separate subnets are considered to outweigh the multilink model's drawbacks as described in [RFC4903].
在蓝牙LE微微网模型（参见第2.2节）中，每个外围设备都有一个到中心的单独链路，中心设备充当IPv6路由器，而不是链路层交换机。如[RFC4903]中所述，IPv6的传统用法预期IPv6子网在链路层跨越单个链路。由于蓝牙LE上的IPv6适用于受约束的节点以及物联网用例和环境，因此在每个外围中心链路上实现单独的子网以及子网之间的路由的复杂性似乎过高。在蓝牙LE情况下，将中央设备与其连接的外围设备之间的点对点链路集合视为单个多链路子网而不是多个独立子网的好处被认为超过了[RFC4903]中所述的多链路模型的缺点。
Hence, a multilink model has been chosen, as further illustrated in Figure 4. Because of this, link-local multicast communications can happen only within a single Bluetooth LE 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 ensures address collisions do not occur (see Section 3.2.3) and forwards packets sent by one 6LN to another.
因此，选择了多链接模型，如图4所示。因此，链路本地多播通信只能在单个蓝牙LE连接内发生；因此，不可能使用链路本地地址进行6LN到6LN通信。连接到同一个6LBR的6LN必须使用子网上使用的共享前缀相互通信。6LBR确保不会发生地址冲突（参见第3.2.3节），并将一个6LN发送的数据包转发给另一个6LN。
In a typical scenario, the Bluetooth LE network is connected to the Internet as shown in the Figure 4. In this scenario, the Bluetooth LE star is deployed as one subnet, using one /64 IPv6 prefix, with each spoke representing an individual link. The 6LBR is acting as router and forwarding packets between 6LNs and to and from Internet.
在典型场景中，蓝牙LE网络连接到互联网，如图4所示。在此场景中，蓝牙LE star部署为一个子网，使用一个/64 IPv6前缀，每个分支表示一个单独的链路。6LBR充当路由器，在6LNs之间转发数据包，并将数据包发送到Internet。
/
.---------------. /
/ 6LN \ /
/ \ \ /
| \ | /
| 6LN ----------- 6LBR ----- | Internet
| <--Link--> / | \
\ / / \
\ 6LN / \
'---------------' \
\
/
.---------------. /
/ 6LN \ /
/ \ \ /
| \ | /
| 6LN ----------- 6LBR ----- | Internet
| <--Link--> / | \
\ / / \
\ 6LN / \
'---------------' \
\
<------ Subnet -----><-- IPv6 connection -->
to Internet
<------ Subnet -----><-- IPv6 connection -->
to Internet
Figure 4: Bluetooth LE Network Connected to the Internet
图4：连接到Internet的蓝牙LE网络
In some scenarios, the Bluetooth LE network may transiently or permanently be an isolated network as shown in the Figure 5. In this case, the whole star consists of a single subnet with multiple links, where 6LBR is at central, routing packets between 6LNs. In the simplest case, the isolated network has one 6LBR and one 6LN.
在某些情况下，蓝牙LE网络可能暂时或永久是一个隔离网络，如图5所示。在这种情况下，整个star由一个子网和多个链路组成，其中6LBR位于中心，在6LN之间路由数据包。在最简单的情况下，隔离网络有一个6LBR和一个6LN。
.-------------------.
/ \
/ 6LN 6LN \
/ \ / \
| \ / |
| 6LN --- 6LBR --- 6LN |
| / \ |
\ / \ /
\ 6LN 6LN /
\ /
'-------------------'
<--------- Subnet ---------->
.-------------------.
/ \
/ 6LN 6LN \
/ \ / \
| \ / |
| 6LN --- 6LBR --- 6LN |
| / \ |
\ / \ /
\ 6LN 6LN /
\ /
'-------------------'
<--------- Subnet ---------->
Figure 5: Isolated Bluetooth LE Network
图5：隔离蓝牙LE网络
At network interface initialization, both 6LN and 6LBR SHALL generate and assign to the Bluetooth LE network interface IPv6 link-local addresses [RFC4862] based on the 48-bit Bluetooth device addresses (see Section 2.3) that were used for establishing the underlying Bluetooth LE connection. A 6LN and a 6LBR are RECOMMENDED to use private Bluetooth device addresses. A 6LN SHOULD pick a different Bluetooth device address for every Bluetooth LE connection with a 6LBR, and a 6LBR SHOULD periodically change its random Bluetooth
在网络接口初始化时，6LN和6LBR应根据用于建立基础蓝牙LE连接的48位蓝牙设备地址（参见第2.3节）生成并分配给蓝牙LE网络接口IPv6链路本地地址[RFC4862]。建议6LN和6LBR使用专用蓝牙设备地址。6LN应为与6LBR的每个蓝牙LE连接选择不同的蓝牙设备地址，6LBR应定期更改其随机蓝牙
device address. Following the guidance of [RFC7136], a 64-bit Interface Identifier (IID) is formed from the 48-bit Bluetooth device address by inserting two octets, with hexadecimal values of 0xFF and 0xFE in the middle of the 48-bit Bluetooth device address as shown in Figure 6. In the figure, letter 'b' represents a bit from the Bluetooth device address, copied as is without any changes on any bit. This means that no bit in the IID indicates whether the underlying Bluetooth device address is public or random.
设备地址。在[RCF7136]的指导下，64位接口标识符（IID）由48位蓝牙设备地址形成，通过插入两个八位字节，在48位蓝牙设备地址的中间，具有0xFF和0xFe的十六进制值，如图6所示。在图中，字母“b”表示蓝牙设备地址中的一个位，按原样复制，任何位都没有任何变化。这意味着IID中没有任何位指示基础蓝牙设备地址是公共地址还是随机地址。
|0 1|1 3|3 4|4 6|
|0 5|6 1|2 7|8 3|
+----------------+----------------+----------------+----------------+
|bbbbbbbbbbbbbbbb|bbbbbbbb11111111|11111110bbbbbbbb|bbbbbbbbbbbbbbbb|
+----------------+----------------+----------------+----------------+
|0 1|1 3|3 4|4 6|
|0 5|6 1|2 7|8 3|
+----------------+----------------+----------------+----------------+
|bbbbbbbbbbbbbbbb|bbbbbbbb11111111|11111110bbbbbbbb|bbbbbbbbbbbbbbbb|
+----------------+----------------+----------------+----------------+
Figure 6: Formation of IID from Bluetooth Device Address
图6：从蓝牙设备地址形成IID
The IID is then prepended with the prefix fe80::/64, as described in RFC 4291 [RFC4291] and as depicted in Figure 7. The same link-local address SHALL be used for the lifetime of the Bluetooth LE L2CAP channel. (After a Bluetooth LE logical link has been established, it is referenced with a Connection Handle in HCI. Thus, possibly changing device addresses do not impact data flows within existing L2CAP channels. Hence, there is no need to change IPv6 link-local addresses even if devices change their random device addresses during L2CAP channel lifetime).
然后，IID前面加上前缀fe80:：/64，如RFC 4291[RFC4291]所述，如图7所示。在蓝牙LE L2CAP信道的生命周期内，应使用相同的链路本地地址。（建立蓝牙LE逻辑链路后，它在HCI中被连接句柄引用。因此，可能更改的设备地址不会影响现有L2CAP通道内的数据流。因此，即使设备在L2CAP通道生命周期内更改其随机设备地址，也无需更改IPv6链路本地地址）。
10 bits 54 bits 64 bits
+----------+-----------------+----------------------+
|1111111010| zeros | Interface Identifier |
+----------+-----------------+----------------------+
10 bits 54 bits 64 bits
+----------+-----------------+----------------------+
|1111111010| zeros | Interface Identifier |
+----------+-----------------+----------------------+
Figure 7: IPv6 Link-Local Address in Bluetooth LE
图7:Bluetooth LE中的IPv6链路本地地址
A 6LN MUST join the all-nodes multicast address. There is no need for 6LN to join the solicited-node multicast address, since 6LBR will know device addresses and hence link-local addresses of all connected 6LNs. The 6LBR will ensure no two devices with the same Bluetooth LE device address are connected at the same time. Detection of duplicate link-local addresses is performed by the process on the 6LBR responsible for the discovery of IP-enabled Bluetooth LE nodes and for starting Bluetooth LE connection establishment procedures. This approach increases the complexity of 6LBR, but reduces power consumption on both 6LN and 6LBR in the link establishment phase by reducing the number of mandatory packet transmissions.
6LN必须加入所有节点的多播地址。6LN不需要加入请求的节点多播地址，因为6LBR将知道设备地址，从而链接所有连接的6LN的本地地址。6LBR将确保不会同时连接具有相同蓝牙LE设备地址的两个设备。重复链路本地地址的检测由6LBR上负责发现启用IP的蓝牙LE节点和启动蓝牙LE连接建立过程的进程执行。这种方法增加了6LBR的复杂性，但通过减少强制数据包传输的数量，降低了链路建立阶段6LN和6LBR的功耗。
After link-local address configuration, the 6LN sends Router Solicitation messages as described in [RFC4861], Section 6.3.7.
链路本地地址配置后，6LN发送路由器请求消息，如[RFC4861]第6.3.7节所述。
For non-link-local addresses, 6LNs SHOULD NOT be configured to embed
the Bluetooth device address in the IID by default. Alternative
schemes such as Cryptographically Generated Addresses (CGAs)
[RFC3972], privacy extensions [RFC4941], Hash-Based Addresses (HBAs)
[RFC5535], DHCPv6 [RFC3315], or static, semantically opaque addresses
[RFC7217] SHOULD be used by default. In situations where the
Bluetooth device address is known to be a private device address and/
or the header compression benefits of embedding the device address in
the IID are required to support deployment constraints, 6LNs MAY form
a 64-bit IID by utilizing the 48-bit Bluetooth device address. The
non-link-local addresses that a 6LN generates MUST be registered with
the 6LBR as described in Section 3.2.3.
For non-link-local addresses, 6LNs SHOULD NOT be configured to embed
the Bluetooth device address in the IID by default. Alternative
schemes such as Cryptographically Generated Addresses (CGAs)
[RFC3972], privacy extensions [RFC4941], Hash-Based Addresses (HBAs)
[RFC5535], DHCPv6 [RFC3315], or static, semantically opaque addresses
[RFC7217] SHOULD be used by default. In situations where the
Bluetooth device address is known to be a private device address and/
or the header compression benefits of embedding the device address in
the IID are required to support deployment constraints, 6LNs MAY form
a 64-bit IID by utilizing the 48-bit Bluetooth device address. The
non-link-local addresses that a 6LN generates MUST be registered with
the 6LBR as described in Section 3.2.3.
The tool for a 6LBR to obtain an IPv6 prefix for numbering the Bluetooth LE network is out of scope of this document, but can be, for example, accomplished via DHCPv6 Prefix Delegation [RFC3633] or by using Unique Local IPv6 Unicast Addresses (ULAs) [RFC4193]. Due to the link model of the Bluetooth LE (see Section 3.2.1) the 6LBR MUST set the "on-link" flag (L) to zero in the Prefix Information Option in Neighbor Discovery messages [RFC4861] (see Section 3.2.3). This will cause 6LNs to always send packets to the 6LBR, including the case when the destination is another 6LN using the same prefix.
6LBR获取用于对蓝牙LE网络进行编号的IPv6前缀的工具不在本文档的范围内，但可以通过DHCPv6前缀委托[RFC3633]或使用唯一的本地IPv6单播地址（ULA）[RFC4193]来实现。由于蓝牙LE的链路型号（参见第3.2.1节），6LBR必须在邻居发现消息[RFC4861]的前缀信息选项中将“链路上”标志（L）设置为零（参见第3.2.3节）。这将导致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. Bluetooth LE does not support mesh networks; hence, only those aspects that apply to a star topology are considered.
“低功耗无线个人区域网络（6LoWPANs）上IPv6的邻居发现优化”[RFC6775]描述了适用于多种6LoWPAN拓扑（包括网状拓扑）的邻居发现方法。蓝牙LE不支持网状网络；因此，只考虑那些适用于星形拓扑的方面。
The following aspects of the Neighbor Discovery optimizations [RFC6775] are applicable to Bluetooth LE 6LNs:
邻居发现优化[RFC6775]的以下方面适用于蓝牙LE 6LNs：
1. A Bluetooth LE 6LN MUST NOT register its link-local address. A Bluetooth LE 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. If the 6LN registers multiple addresses that are not based on Bluetooth device address for the same compression context, the header compression efficiency will decrease (see Section 3.2.4).
1. 蓝牙LE 6LN不得注册其链路本地地址。蓝牙LE 6LN必须通过使用地址注册选项（ARO）发送邻居请求（NS）消息，向6LBR注册其非链路本地地址，并相应地处理邻居公告（NA）。无论使用何种方法生成IID，都必须发送带有ARO选项的NS。如果6LN为同一压缩上下文注册了多个不基于蓝牙设备地址的地址，则报头压缩效率将降低（参见第3.2.4节）。
2. For sending Router Solicitations and processing Router Advertisements, the Bluetooth LE 6LNs MUST follow Sections 5.3 and 5.4 of [RFC6775], respectively.
2. 对于发送路由器请求和处理路由器广告，蓝牙LE 6LNs必须分别遵循[RFC6775]的第5.3节和第5.4节。
Header compression as defined in RFC 6282 [RFC6282], which specifies the compression format for IPv6 datagrams on top of IEEE 802.15.4, is REQUIRED as the basis for IPv6 header compression on top of Bluetooth LE. All headers MUST be compressed according to the encoding formats described in RFC 6282 [RFC6282].
RFC 6282[RFC6282]中定义的报头压缩指定了IEEE 802.15.4之上IPv6数据报的压缩格式，需要将其作为蓝牙LE之上IPv6报头压缩的基础。必须根据RFC 6282[RFC6282]中描述的编码格式压缩所有标题。
The Bluetooth LE's star topology structure and ARO 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 Bluetooth LE.
可以利用蓝牙LE的星形拓扑结构和ARO来提供地址压缩机制。下面的文字描述了蓝牙LE之上IPv6地址压缩的原理。
The ARO option requires use of a 64-bit Extended Unique Identifier (EUI-64) [RFC6775]. In the case of Bluetooth LE, the field SHALL be filled with the 48-bit device address used by the Bluetooth LE node converted into 64-bit Modified EUI-64 format [RFC4291].
ARO选项需要使用64位扩展唯一标识符（EUI-64）[RFC6775]。对于蓝牙LE，该字段应填写蓝牙LE节点使用的48位设备地址，该地址转换为64位修改的EUI-64格式[RFC4291]。
To enable efficient header compression, when the 6LBR sends a Router Advertisement, it MUST include a 6LoWPAN Context Option (6CO) [RFC6775] matching each address prefix advertised via a Prefix Information Option (PIO) [RFC4861] for use in stateless address autoconfiguration.
为了实现高效的报头压缩，当6LBR发送路由器公告时，它必须包括一个6LoWPAN上下文选项（6CO）[RFC6775]，该选项与通过前缀信息选项（PIO）[RFC4861]播发的每个地址前缀相匹配，以用于无状态地址自动配置。
When a 6LN is sending a packet to a 6LBR, it MUST fully elide the source address if it is a link-local address. For other packets to or through a 6LBR with a non-link-local source address that the 6LN has registered with ARO to the 6LBR for the indicated prefix, the source address MUST be fully elided if it is the latest address that the 6LN has registered for the indicated prefix. If a source non-link-local address is not the latest registered, then the 64 bits of the IID SHALL be fully carried in-line (SAM=01), or if the first 48 bits of the IID match with the latest registered address, then the last 16 bits of the IID SHALL be carried in-line (SAM=10). That is, if SAC=0 and SAM=11, the 6LN MUST be using the link-local IPv6 address derived from the Bluetooth LE device address, and if SAC=1 and SAM=11, the 6LN MUST have registered the source IPv6 address with the prefix related to the compression context, and the 6LN MUST be referring to the latest registered address related to the compression context. The IPv6 address MUST be considered to be registered only after the 6LBR has sent a Neighbor Advertisement with an ARO having its status field set to success. The destination IPv6 address MUST be fully elided if the destination address is the 6LBR's link-local address based on the 6LBR's Bluetooth device address (DAC=0, DAM=11).
当6LN向6LBR发送数据包时，如果是链路本地地址，则必须完全删除源地址。对于发送到或通过6LBR的其他数据包，其非链路本地源地址为6LN已向ARO注册到6LBR的指定前缀，如果源地址是6LN已为指定前缀注册的最新地址，则必须完全省略。如果源非链路本地地址不是最新注册的地址，则IID的64位应完全在线携带（SAM=01），或者如果IID的前48位与最新注册地址匹配，则IID的最后16位应在线携带（SAM=10）。也就是说，如果SAC=0和SAM=11，则6LN必须使用从蓝牙LE设备地址派生的链路本地IPv6地址，如果SAC=1和SAM=11，则6LN必须使用与压缩上下文相关的前缀注册源IPv6地址，并且6LN必须引用与压缩上下文相关的最新注册地址。只有在6LBR发送了一个ARO状态字段设置为success的邻居播发后，才能认为IPv6地址已注册。如果目标地址是基于6LBR蓝牙设备地址（DAC=0，DAM=11）的6LBR链路本地地址，则必须完全省略目标IPv6地址。
The destination IPv6 address MUST be fully or partially elided if context has been set up for the destination address, for example, DAC=0 and DAM=01 when destination prefix is link-local, and DAC=1 and DAM=01 if compression context has been configured for the destination prefix used.
如果已为目标地址设置了上下文，则必须完全或部分删除目标IPv6地址，例如，当目标前缀为本地链路时，DAC=0和DAM=01；如果已为使用的目标前缀配置了压缩上下文，则DAC=1和DAM=01。
When a 6LBR is transmitting packets to a 6LN, it MUST fully elide the source IID if the source IPv6 address is the link-local address based on the 6LBR's Bluetooth device address (SAC=0, SAM=11), and it MUST elide the source prefix or address if a compression context related to the IPv6 source address has been set up. The 6LBR also MUST fully elide the destination IPv6 address if it is the link-local address based on the 6LN's Bluetooth device address (DAC=0, DAM=11), or if the destination address is the latest registered by the 6LN with ARO for the indicated context (DAC=1, DAM=11). If the destination address is a non-link-local address and not the latest registered, then the 6LN MUST either include the IID part fully in-line (DAM=01) or, if the first 48 bits of the IID match to the latest registered address, then elide those 48 bits (DAM=10).
当6LBR向6LN传输数据包时，如果源IPv6地址是基于6LBR蓝牙设备地址（SAC=0，SAM=11）的链路本地地址，则必须完全删除源IID，如果已设置与IPv6源地址相关的压缩上下文，则必须删除源前缀或地址。如果目标IPv6地址是基于6LN蓝牙设备地址（DAC=0，DAM=11）的链路本地地址，或者如果目标地址是6LN与ARO针对指定上下文（DAC=1，DAM=11）注册的最新地址，则6LBR还必须完全删除目标IPv6地址。如果目标地址是非链路本地地址且不是最新注册的地址，则6LN必须包括完全串联的IID部分（DAM=01），或者，如果IID的前48位与最新注册地址匹配，则删除这48位（DAM=10）。
When a 6LN transmits an IPv6 packet to a remote destination using global Unicast IPv6 addresses, if a context is defined for the 6LN's global IPv6 address, the 6LN has to indicate this context in the corresponding source fields of the compressed IPv6 header as per Section 3.1 of RFC 6282 [RFC6282] and has to elide the full IPv6 source address previously registered with ARO (if using the latest registered address; otherwise, part or all of the IID may have to be transmitted in-line). For this, the 6LN MUST use the following settings in the IPv6 compressed header: SAC=1 and SAM=11. The CID may be set 0 or 1, depending on which context is used. 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 the device has registered with ARO. If a context is defined for the IPv6 destination address, the 6LN has to also indicate this context in the corresponding destination fields of the compressed IPv6 header, and elide the prefix of or the full destination IPv6 address. For this, the 6LN MUST set the DAM field of the compressed IPv6 header as DAM=01 (if the context covers a 64-bit prefix) or as DAM=11 (if the context covers a full 128-bit address). DAC MUST be set to 1. Note that when a context is defined for the IPv6 destination address, the 6LBR can infer the elided destination prefix by using the context.
当6LN使用全局单播IPv6地址向远程目的地传输IPv6数据包时，如果为6LN的全局IPv6地址定义了上下文，则6LN必须根据RFC 6282[RFC6282]第3.1节在压缩IPv6报头的相应源字段中指示该上下文并且必须删除之前向ARO注册的完整IPv6源地址（如果使用最新注册地址；否则，部分或全部IID可能必须在线传输）。为此，6LN必须在IPv6压缩标题中使用以下设置：SAC=1和SAM=11。CID可以设置为0或1，具体取决于使用的上下文。在这种情况下，6LBR可以推断省略的IPv6源地址，因为1）6LBR之前已将前缀分配给6LNs；2）6LBR维护一个邻居缓存，该缓存将设备地址和设备已向ARO注册的IID关联起来。如果为IPv6目标地址定义了上下文，则6LN还必须在压缩IPv6报头的相应目标字段中指示该上下文，并省略目标IPv6地址的前缀或完整地址。为此，6LN必须将压缩IPv6标头的DAM字段设置为DAM=01（如果上下文包含64位前缀）或DAM=11（如果上下文包含完整的128位地址）。DAC必须设置为1。请注意，当为IPv6目标地址定义上下文时，6LBR可以使用上下文推断省略的目标前缀。
When a 6LBR receives an IPv6 packet sent by a remote node outside the Bluetooth LE network, and the destination of the packet is a 6LN, if a context is defined for the prefix of the 6LN's global IPv6 address, the 6LBR has to indicate this context in the corresponding destination fields of the compressed IPv6 header. The 6LBR has to elide the IPv6 destination address of the packet before forwarding it, if the IPv6 destination address is inferable by the 6LN. For this, the 6LBR will set the DAM field of the IPv6 compressed header as DAM=11 (if the address is the latest 6LN has registered). DAC needs to be set to 1. If a context is defined for the IPv6 source address, the 6LBR needs to indicate this context in the source fields of the compressed IPv6 header and elide that prefix as well. For this, the 6LBR needs to set the SAM field of the IPv6 compressed header as SAM=01 (if the context covers a 64-bit prefix) or SAM=11 (if the context covers a full 128-bit address). SAC is to be set to 1.
当6LBR接收到蓝牙LE网络外部远程节点发送的IPv6数据包，且数据包的目的地为6LN时，如果为6LN的全局IPv6地址前缀定义了上下文，则6LBR必须在压缩IPv6报头的相应目的地字段中指示此上下文。如果6LN可以推断IPv6目标地址，则6LBR必须在转发数据包之前删除数据包的IPv6目标地址。为此，6LBR将IPv6压缩头的DAM字段设置为DAM=11（如果地址是最新注册的6LN）。DAC需要设置为1。如果为IPv6源地址定义了上下文，则6LBR需要在压缩IPv6标头的源字段中指示该上下文，并删除该前缀。为此，6LBR需要将IPv6压缩头的SAM字段设置为SAM=01（如果上下文包含64位前缀）或SAM=11（如果上下文包含完整的128位地址）。将SAC设置为1。
As described above, a 6LN can register multiple non-link-local addresses that map to the same compression context. From the multiple address registered, only the latest address can be fully elided (SAM=11, DAM=11), and the IIDs of previously registered addresses have to be transmitted fully in-line (SAM=01, DAM=01) or, in the best case, can be partially elided (SAM=10, DAM=10). This is illustrated in the example below:
如上所述，6LN可以注册映射到同一压缩上下文的多个非链接本地地址。从注册的多个地址中，只有最新地址可以完全省略（SAM=11，DAM=11），先前注册地址的IID必须完全在线传输（SAM=01，DAM=01），或者在最佳情况下，可以部分省略（SAM=10，DAM=10）。下面的示例对此进行了说明：
1. The 6LN registers first address 2001:db8::1111:2222:3333:4444 to a 6LBR. At this point the address can be fully elided using SAC=1/SAM=11 or DAC=1/DAM=11.
1. 6LN将第一个地址2001:db8:：1111:2222:3333:4444注册到6LBR。此时，可以使用SAC=1/SAM=11或DAC=1/DAM=11完全省略地址。
2. The 6LN registers second address 2001:db8::1111:2222:3333:5555 to the 6LBR. As the second address is now the latest registered, it can be fully elided using SAC=1/SAM=11 or DAC=1/DAM=11. The first address can now be partially elided using SAC=1/SAM=10 or DAC=1/DAM=10, as the first 112 bits of the address are the same between the first and the second registered addresses.
2. 6LN将第二个地址2001:db8:：1111:2222:3333:5555注册到6LBR。由于第二个地址现在是最新注册的地址，因此可以使用SAC=1/SAM=11或DAC=1/DAM=11将其完全删除。现在可以使用SAC=1/SAM=10或DAC=1/DAM=10部分省略第一地址，因为地址的前112位在第一和第二注册地址之间相同。
3. Expiration of registration time for the first or the second address has no impact on the compression. Hence, even if the most recently registered address expires, the first address can only be partially elided (SAC=1/SAM=10, DAC=1/DAM=10). The 6LN can register a new address, or re-register an expired address, to become able to again fully elide an address.
3. 第一个或第二个地址的注册时间到期对压缩没有影响。因此，即使最近注册的地址过期，第一个地址也只能部分省略（SAC=1/SAM=10，DAC=1/DAM=10）。6LN可以注册一个新地址，或重新注册一个过期地址，以便能够再次完全删除地址。
The Bluetooth LE Link Layer does not support multicast. Hence, traffic is always unicast between two Bluetooth LE 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 must be taken if the central is battery powered. To further conserve power, the 6LBR MUST keep track of multicast listeners at Bluetooth LE link-level granularity (not at subnet granularity), and it MUST NOT forward multicast packets to 6LNs that have not registered as listeners for multicast groups the packets belong to. In the opposite direction, a 6LN always has to send packets to or through the 6LBR. Hence, when a 6LN needs to transmit an IPv6 multicast packet, the 6LN will unicast the corresponding Bluetooth LE packet to the 6LBR.
蓝牙LE链路层不支持多播。因此，流量始终在两个蓝牙LE节点之间单播。即使6LBR连接到多个6LN，6LBR也无法对所有连接的6LN进行多播。如果6LBR需要向其所有6LN发送多播数据包，则必须复制该数据包并在每个链路上单播。但是，这可能不节能，如果中央空调由电池供电，则必须特别小心。为了进一步节省电源，6LBR必须在蓝牙LE链路级别粒度（而不是子网粒度）上跟踪多播侦听器，并且不得将多播数据包转发给尚未注册为数据包所属多播组侦听器的6LN。相反，6LN必须始终向或通过6LBR发送数据包。因此，当6LN需要传输IPv6多播数据包时，6LN将单播相应的蓝牙LE数据包到6LBR。
The transmission of IPv6 over Bluetooth LE links and IPv6 over IEEE 802.15.4 have similar requirements and concerns for security. Security considerations for the Bluetooth LE Link Layer are covered by the IPSP [IPSP].
通过蓝牙LE链路传输IPv6和通过IEEE 802.15.4传输IPv6对安全性有类似的要求和考虑。IPSP[IPSP]涵盖了蓝牙LE链路层的安全注意事项。
Bluetooth LE Link Layer supports encryption and authentication by using the Counter with CBC-MAC (CCM) mechanism [RFC3610] and a 128-bit AES block cipher. Upper-layer security mechanisms may exploit this functionality when it is available. (Note: CCM does not consume octets from the maximum per-packet L2CAP data size, since the link-layer data unit has a specific field for them when they are used.)
蓝牙LE链路层通过使用带有CBC-MAC（CCM）机制[RFC3610]的计数器和128位AES分组密码来支持加密和身份验证。上层安全机制可以在该功能可用时利用该功能。（注意：CCM不使用最大每包L2CAP数据大小的八位字节，因为链路层数据单元在使用它们时有一个特定字段。）
Key management in Bluetooth LE is provided by the Security Manager Protocol (SMP), as defined in [BTCorev4.1].
蓝牙LE中的密钥管理由[BTCorev4.1]中定义的安全管理器协议（SMP）提供。
The Direct Test Mode offers two setup alternatives: with and without accessible HCI. In designs with accessible HCI, the so-called upper tester communicates through the HCI (which may be supported by Universal Asynchronous Receiver Transmitter (UART), Universal Serial Bus (USB), and Secure Digital transports), with the Physical and Link Layers of the Bluetooth LE device under test. In designs without accessible HCI, the upper tester communicates with the device under test through a two-wire UART interface. The Bluetooth specification [BTCorev4.1] does not provide security mechanisms for the communication between the upper tester and the device under test in
直接测试模式提供了两种设置选项：带和不带可访问HCI。在具有可访问HCI的设计中，所谓的上层测试仪通过HCI（可由通用异步收发器（UART）、通用串行总线（USB）和安全数字传输支持）与被测蓝牙LE设备的物理层和链路层进行通信。在没有可访问HCI的设计中，上部测试仪通过双线UART接口与被测设备进行通信。蓝牙规范[BTCorev4.1]没有为上层测试仪和中测试设备之间的通信提供安全机制
either case. Nevertheless, an attacker needs to physically connect a device (via one of the wired HCI types) to the device under test to be able to interact with the latter.
不管是哪种情况。然而，攻击者需要将设备（通过有线HCI类型之一）物理连接到被测设备，才能与后者交互。
The IPv6 link-local address configuration described in Section 3.2.2 only reveals information about the 6LN to the 6LBR that the 6LBR already knows from the link-layer connection. This means that a device using Bluetooth privacy features reveals the same information in its IPv6 link-local addresses as in its device addresses. Respectively, a device not using privacy at the Bluetooth level will not have privacy at the IPv6 link-local address either. For non-link-local addresses, implementations are recommended not to embed the Bluetooth device address in the IID by default and instead support, for example, [RFC3315], [RFC3972], [RFC4941], [RFC5535], or [RFC7217].
第3.2.2节中描述的IPv6链路本地地址配置仅显示6LN到6LBR的信息，6LBR已经从链路层连接中知道这些信息。这意味着使用蓝牙隐私功能的设备在其IPv6链路本地地址中显示的信息与其设备地址中的信息相同。分别地，在蓝牙级别不使用隐私的设备在IPv6链路本地地址也不会有隐私。对于非链路本地地址，建议在默认情况下不要将蓝牙设备地址嵌入IID，而是支持，例如，[RFC3315]、[RFC3972]、[RFC4941]、[RFC5535]或[RFC7217]。
A malicious 6LN may attempt to perform a denial-of-service attack on the Bluetooth LE network, for example, by flooding packets. This sort of attack is mitigated by the fact that link-local multicast is not bridged between Bluetooth LE links and by 6LBR being able to rate-limit packets sent by each 6LN by making smart use of the Bluetooth LE L2CAP credit-based flow-control mechanism.
恶意6LN可能试图在蓝牙LE网络上执行拒绝服务攻击，例如，通过洪泛数据包。这种攻击通过以下事实得以缓解：链路本地多播在蓝牙LE链路之间未桥接，并且6LBR能够通过智能使用基于蓝牙LE L2CAP信用的流量控制机制对每个6LN发送的数据包进行速率限制。
[BTCorev4.1] Bluetooth Special Interest Group, "Bluetooth Core Specification Version 4.1", December 2013, <https://www.bluetooth.org/en-us/specification/adopted-specifications>.
[BTCorev4.1]蓝牙特别兴趣小组，“蓝牙核心规范版本4.1”，2013年12月<https://www.bluetooth.org/en-us/specification/adopted-specifications>.
[IPSP] Bluetooth Special Interest Group, "Bluetooth Internet Protocol Support Profile Specification Version 1.0.0", December 2014, <https://www.bluetooth.org/en-us/specification/adopted-specifications>.
[IPSP]蓝牙特别兴趣小组，“蓝牙互联网协议支持配置文件规范1.0.0版”，2014年12月<https://www.bluetooth.org/en-us/specification/adopted-specifications>.
[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>.
[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>.
[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>.
[IEEE802] IEEE, "IEEE Standard for Local and Metropolitan Area Networks: Overview and Architecture", IEEE 802, DOI 10.1109/ieeestd.2002.93395, <http://ieeexplore.ieee.org/servlet/opac?punumber=7732>.
[IEEE802]IEEE，“局域网和城域网的IEEE标准：概述和体系结构”，IEEE 802，DOI 10.1109/ieeestd.2002.93395<http://ieeexplore.ieee.org/servlet/opac?punumber=7732>.
[IEEE802.15.4] IEEE, "IEEE Standard for Local and metropolitan area networks--Part 15.4: Low-Rate Wireless Personal Area Networks (LR-WPANs)", IEEE 802.15.4, DOI 10.1109/ieeestd.2011.6012487, <http://ieeexplore.ieee.org/servlet/ opac?punumber=6012485>.
[IEEE802.15.4]IEEE，“局域网和城域网的IEEE标准——第15.4部分：低速无线个人区域网（LR WPAN）”，IEEE 802.15.4，DOI 10.1109/ieeestd.2011.6012487<http://ieeexplore.ieee.org/servlet/ opac？punumber=6012485>。
[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>.
[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>.
[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>.
[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>.
[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>.
[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>.
[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>.
Acknowledgements
致谢
The Bluetooth, Bluetooth Smart, and Bluetooth Smart Ready marks are registered trademarks owned by Bluetooth SIG, Inc.
Bluetooth、Bluetooth Smart和Bluetooth Smart Ready标记是Bluetooth SIG，Inc.拥有的注册商标。
Carsten Bormann, Samita Chakrabarti, Niclas Comstedt, Alissa Cooper, Elwyn Davies, Brian Haberman, Marcel De Kogel, Jouni Korhonen, Chris Lonvick, Erik Nordmark, Erik Rivard, Dave Thaler, Pascal Thubert, Xavi Vilajosana, and Victor Zhodzishsky provided valuable feedback for this document.
Carsten Bormann、Samita Chakrabarti、Niclas Comstedt、Alissa Cooper、Elwyn Davies、Brian Haberman、Marcel De Kogel、Jouni Korhonen、Chris Lonvick、Erik Nordmark、Erik Rivard、Dave Thaler、Pascal Thubert、Xavi Vilajosana和Victor Zhodzissky为本文件提供了宝贵的反馈。
The authors would like to give special acknowledgements to Krishna Shingala, Frank Berntsen, and Bluetooth SIG's Internet Working Group for providing significant feedback and improvement proposals for this document.
作者特别感谢Krishna Shingala、Frank Berntsen和Bluetooth SIG互联网工作组为本文件提供了重要反馈和改进建议。
Carles Gomez has been supported in part by the Spanish Government Ministerio de Economia y Competitividad through project TEC2012-32531, and FEDER.
西班牙政府经济和竞争部通过TEC2012-32531项目和FEDER为Carles Gomez提供了部分支持。
Johanna Nieminen worked on this RFC in 2011-2012 while at Nokia and would like to thank Nokia for supporting the project.
Johanna Nieminen在诺基亚工作期间于2011-2012年参与了该RFC，并感谢诺基亚对该项目的支持。
Contributors
贡献者
Kanji Kerai, Jari Mutikainen, David Canfeng-Chen, and Minjun Xi from Nokia contributed significantly to this document.
诺基亚、Kanji Kerai、Jari Mutikainen、David Canfeng Chen和明俊席对此文件做出了重大贡献。
Authors' Addresses
作者地址
Johanna Nieminen TeliaSonera
Johanna Nieminen TeliaSonera
Email: johannamaria.nieminen@gmail.com
Email: johannamaria.nieminen@gmail.com
Teemu Savolainen Nokia Visiokatu 3 Tampere 33720 Finland
Teemu Savolainen诺基亚Visiokatu 3坦佩雷33720芬兰
Email: teemu.savolainen@nokia.com
Email: teemu.savolainen@nokia.com
Markus Isomaki Nokia Karaportti 2-4 Espoo 02610 Finland
Markus Isomaki诺基亚卡拉波特2-4 Espoo 02610芬兰
Email: markus.isomaki@nokia.com
Email: markus.isomaki@nokia.com
Basavaraj Patil AT&T 1410 East Renner Road Richardson, TX 75082 United States
美国德克萨斯州理查森市雷纳东路1410号巴萨瓦拉吉帕蒂尔AT&T 75082
Email: basavaraj.patil@att.com
Email: basavaraj.patil@att.com
Zach Shelby ARM 150 Rose Orchard Way San Jose, CA 95134 United States
美国加利福尼亚州圣何塞玫瑰园大道150号Zach Shelby ARM，邮编95134
Email: zach.shelby@arm.com
Email: zach.shelby@arm.com
Carles Gomez Universitat Politecnica de Catalunya/i2CAT C/Esteve Terradas, 7 Castelldefels 08860 Spain
卡莱斯·戈麦斯加泰罗尼亚理工大学/i2CAT C/Esteve Terradas，7 Casteldefels 08860西班牙
Email: carlesgo@entel.upc.edu
Email: carlesgo@entel.upc.edu