---
tags: 6LoBTLE,BLE,IPv6,IoT
---

# RFC 7668 - IPv6 over Bluetooth LE
[RFC7668](https://tools.ietf.org/html/rfc7668) 重點紀錄

參考網頁:
* [ipv6名詞解釋](https://hanteye01.blog.fc2.com/blog-entry-1.html)
## 1. Introduction
1. 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 Stateless Autoconfiguration](https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/ipv6_basic/configuration/xe-3se/5700/ip6-statlss-auto-xe.html#GUID-2394A69B-69E8-4A21-A503-059628CFCE63)
2. many mechanisms defined for IPv6 over IEEE 802.15.4 can be applied to the transmission of IPv6 on Bluetooth LE links.
IPv6 over IEEE 802.15.4:
* [RFC4944](https://tools.ietf.org/pdf/rfc4944.pdf)
* [RFC6282](https://tools.ietf.org/pdf/rfc6282.pdf)
* [RFC6775](https://tools.ietf.org/pdf/rfc6775.pdf)

## 2. Bluetooth Low Energy
1. 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.

### 2.1 Bluetooth LE Stack
1. The Physical Layer ***transmits and receives the actual packets***.
2. The Link Layer is responsible for providing ***medium access, connection establishment, error control, and flow control***.
3. GATT and Bluetooth LE profiles together ***enable the creation of applications in a standardized way*** without using IP.
4. L2CAP provides multiplexing capability by ***multiplexing the data channels*** from the above layers, also provides ***fragmentation and reassembly*** for large data packets.
5. The Security Manager defines a protocol and mechanisms for ***pairing, key distribution, and a security toolbox*** for the Bluetooth LE device.

IPv6 over Bluetooth LE requires an adapted 6LoWPAN layer that ***runs on top of Bluetooth LE L2CAP***.

### 2.2. Roles and Topology for Link Layer
1. central has traditionally been able to manage multiple simultaneous connections with ***a number of*** peripheral.
2. peripheral is commonly connected to a ***single*** central.(Bluetooth 4.1 can also connect to multiple centrals at the same time)
3. In the future, mesh networking may be defined for IPv6 over Bluetooth LE.


### 2.3. Bluetooth LE Device Addressing
1. Every Bluetooth LE device is identified by a ***48-bit*** device address(public device address or random device address).
2. The ***public device addresses*** are based on the IEEE 802 standard.
3. ***Random device addresses*** and the Bluetooth LE privacy feature are described in the Bluetooth Generic Access Profile.There are two types of random device addresses:
* private address:
the first 46 bits are randomized, and the last 2 bits indicate the random address type.(private address可能會重複)
* resolvable
* non-resolvable
* static address:
Once a static address is initialized, it does not change until the device is power cycled(建議間隔15 mins).

### 2.4. Bluetooth LE Packet Sizes and MTU
1. The optimal MTU defined for L2CAP fixed channels over Bluetooth LE is ***27 bytes***(4 bytes header).
2. The link-layer MTU is negotiated separately for each direction(取最小的).
3. fragmentation and reassembly solution is provided by the L2CAP layer(IPv6 packets 1280bytes以上).

## 3. Specification of IPv6 over Bluetooth Low Energy
1. 6LoWPAN standards provide useful functionality for reducing overhead:
* link-local IPv6 addresses and stateless IPv6 address autoconfiguration(3.2.2)
* neighbor Discovery(3.2.3)
* header compression(3.2.4)
2. In Bluetooth LE, a central node is assumed to be less resource constrained than a peripheral node. Hence, ***central and peripheral will act as 6LoWPAN Border Router (6LBR) and a 6LoWPAN Node (6LN)***.

### 3.1. Protocol Stack

### 3.2. Link Model
#### 3.2.1. IPv6 Subnet Model and Internet Connectivity
1. peripherals each have a separate link to the central and the central acts as an IPv6 router rather than a link-layer switch.(跨網域)
2. two scenario:
* 
(6LBR = router)

* 
(switch only)

#### 3.2.2. Stateless Address Autoconfiguration
1. At network interface initialization, both 6LN and 6LBR SHALL generate and assign to the Bluetooth LE network interface IPv6 link-local addresses based on the 48-bit Bluetooth device addresses that were used for establishing the underlying Bluetooth LE connection.
2. 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 device address.
3. 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.
4. The IID is then prepended with the prefix fe80::/64(IPv6 定義Link-local address的固定prefix).
5. A 6LN MUST join the ***all-nodes multicast address***. There is no need for 6LN to join the solicited-node multicast address
6. After link-local address configuration, the 6LN sends Router Solicitation messages.(解析鄰近node的MAC地址)
7. The non-link-local addresses that a 6LN generates MUST be registered with the 6LBR(3.2.3解釋)

#### 3.2.3. Neighbor Discovery
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.
2. For sending Router Solicitations and processing Router Advertisements, the Bluetooth LE 6LNs MUST follow Sections 5.3 and 5.4 of [RFC6775]

#### 3.2.4. Header Compression

#### 3.2.5. Unicast and Multicast Address Mapping
1. traffic is always unicast between two Bluetooth LE nodes. 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.