< draft-ietf-6lo-btle-14.txt   draft-ietf-6lo-btle-15.txt >
6Lo Working Group J. Nieminen 6Lo Working Group J. Nieminen
Internet-Draft T. Savolainen Internet-Draft T. Savolainen
Intended status: Standards Track M. Isomaki Intended status: Standards Track M. Isomaki
Expires: December 27, 2015 Nokia Expires: January 21, 2016 Nokia
B. Patil B. Patil
AT&T AT&T
Z. Shelby Z. Shelby
Arm Arm
C. Gomez C. Gomez
Universitat Politecnica de Catalunya/i2CAT Universitat Politecnica de Catalunya/i2CAT
June 25, 2015 July 20, 2015
IPv6 over BLUETOOTH(R) Low Energy IPv6 over BLUETOOTH(R) Low Energy
draft-ietf-6lo-btle-14 draft-ietf-6lo-btle-15
Abstract Abstract
Bluetooth Smart is the brand name for the Bluetooth low energy Bluetooth Smart is the brand name for the Bluetooth low energy
feature in the Bluetooth specification defined by the Bluetooth feature in the Bluetooth specification defined by the Bluetooth
Special Interest Group. The standard Bluetooth radio has been widely Special Interest Group. The standard Bluetooth radio has been widely
implemented and available in mobile phones, notebook computers, audio implemented and available in mobile phones, notebook computers, audio
headsets and many other devices. The low power version of Bluetooth headsets and many other devices. The low power version of Bluetooth
is a specification that enables the use of this air interface with is a specification that enables the use of this air interface with
devices such as sensors, smart meters, appliances, etc. The low devices such as sensors, smart meters, appliances, etc. The low
skipping to change at page 1, line 48 skipping to change at page 1, line 48
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on December 27, 2015. This Internet-Draft will expire on January 21, 2016.
Copyright Notice Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the Copyright (c) 2015 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Terminology and Requirements Language . . . . . . . . . . 3 1.1. Terminology and Requirements Language . . . . . . . . . . 3
2. Bluetooth Low Energy . . . . . . . . . . . . . . . . . . . . 3 2. Bluetooth Low Energy . . . . . . . . . . . . . . . . . . . . 3
2.1. Bluetooth LE stack . . . . . . . . . . . . . . . . . . . 4 2.1. Bluetooth LE stack . . . . . . . . . . . . . . . . . . . 4
2.2. Link layer roles and topology . . . . . . . . . . . . . . 5 2.2. Link layer roles and topology . . . . . . . . . . . . . . 5
2.3. Bluetooth LE device addressing . . . . . . . . . . . . . 6 2.3. Bluetooth LE device addressing . . . . . . . . . . . . . 6
2.4. Bluetooth LE packet sizes and MTU . . . . . . . . . . . . 6 2.4. Bluetooth LE packet sizes and MTU . . . . . . . . . . . . 6
3. Specification of IPv6 over Bluetooth Low Energy . . . . . . . 6 3. Specification of IPv6 over Bluetooth Low Energy . . . . . . . 6
3.1. Protocol stack . . . . . . . . . . . . . . . . . . . . . 7 3.1. Protocol stack . . . . . . . . . . . . . . . . . . . . . 7
3.2. Link model . . . . . . . . . . . . . . . . . . . . . . . 8 3.2. Link model . . . . . . . . . . . . . . . . . . . . . . . 8
3.2.1. IPv6 Subnet Model . . . . . . . . . . . . . . . . . . 9 3.2.1. IPv6 subnet model and Internet connectivity . . . . . 9
3.2.2. Stateless address autoconfiguration . . . . . . . . . 9 3.2.2. Stateless address autoconfiguration . . . . . . . . . 10
3.2.3. Neighbor discovery . . . . . . . . . . . . . . . . . 11 3.2.3. Neighbor discovery . . . . . . . . . . . . . . . . . 12
3.2.4. Header compression . . . . . . . . . . . . . . . . . 11 3.2.4. Header compression . . . . . . . . . . . . . . . . . 13
3.2.4.1. Remote destination example . . . . . . . . . . . 13 3.2.4.1. Remote destination example . . . . . . . . . . . 14
3.2.4.2. Example of registration of multiple-addresses . . 14 3.2.4.2. Example of registration of multiple-addresses . . 15
3.2.5. Unicast and Multicast address mapping . . . . . . . . 14 3.2.5. Unicast and Multicast address mapping . . . . . . . . 15
3.3. Subnets and Internet connectivity scenarios . . . . . . . 15
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
5. Security Considerations . . . . . . . . . . . . . . . . . . . 16 5. Security Considerations . . . . . . . . . . . . . . . . . . . 16
6. Additional contributors . . . . . . . . . . . . . . . . . . . 17 6. Additional contributors . . . . . . . . . . . . . . . . . . . 17
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 17 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 17
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 17
8.1. Normative References . . . . . . . . . . . . . . . . . . 17 8.1. Normative References . . . . . . . . . . . . . . . . . . 17
8.2. Informative References . . . . . . . . . . . . . . . . . 18 8.2. Informative References . . . . . . . . . . . . . . . . . 18
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20
1. Introduction 1. Introduction
Bluetooth Smart is the brand name for the Bluetooth low energy Bluetooth Smart is the brand name for the Bluetooth low energy
feature (hereinafter, Bluetooth LE) in the Bluetooth specification feature (hereinafter, Bluetooth LE) in the Bluetooth specification
defined by the Bluetooth Special Interest Group. Bluetooth LE is a defined by the Bluetooth Special Interest Group. Bluetooth LE is a
radio technology targeted for devices that operate with very low radio technology targeted for devices that operate with very low
capacity (e.g., coin cell) batteries or minimalistic power sources, capacity (e.g., coin cell) batteries or minimalistic power sources,
which means that low power consumption is essential. Bluetooth LE is which means that low power consumption is essential. Bluetooth LE is
especially attractive technology for Internet of Things applications, especially attractive technology for Internet of Things applications,
skipping to change at page 9, line 12 skipping to change at page 9, line 12
Connection Handle during connection, compression context if any, and Connection Handle during connection, compression context if any, and
from address registration information (see Section 3.2.3). from address registration information (see Section 3.2.3).
Bluetooth LE connections used to build a star topology are point-to- Bluetooth LE connections used to build a star topology are point-to-
point in nature, as Bluetooth broadcast features are not used for point in nature, as Bluetooth broadcast features are not used for
IPv6 over Bluetooth LE (except for discovery of nodes supporting IPv6 over Bluetooth LE (except for discovery of nodes supporting
IPSS). After the peripheral and central have connected at the IPSS). After the peripheral and central have connected at the
Bluetooth LE level, the link can be considered up and IPv6 address Bluetooth LE level, the link can be considered up and IPv6 address
configuration and transmission can begin. configuration and transmission can begin.
3.2.1. IPv6 Subnet Model 3.2.1. IPv6 subnet model and Internet connectivity
In the Bluetooth LE piconet model (see Section 2.2) peripherals each 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 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], router rather than a link layer switch. As discussed in [RFC4903],
conventional usage of IPv6 anticipates IPv6 subnets spanning a single conventional usage of IPv6 anticipates IPv6 subnets spanning a single
link at the link layer. As IPv6 over Bluetooth LE is intended for link at the link layer. As IPv6 over Bluetooth LE is intended for
constrained nodes, and for Internet of Things use cases and constrained nodes, and for Internet of Things use cases and
environments, the complexity of implementing a separate subnet on environments, the complexity of implementing a separate subnet on
each peripheral-central link and routing between the subnets appears each peripheral-central link and routing between the subnets appears
to be excessive. In the Bluetooth LE case, the benefits of treating to be excessive. In the Bluetooth LE case, the benefits of treating
the collection of point-to-point links between a central and its the collection of point-to-point links between a central and its
connected peripherals as a single multilink subnet rather than a connected peripherals as a single multilink subnet rather than a
multiplicity of separate subnets are considered to outweigh the multiplicity of separate subnets are considered to outweigh the
multilink model's drawbacks as described in [RFC4903]. multilink model's drawbacks as described in [RFC4903].
Hence a multilink model has been chosen, as further illustrated in Hence a multilink model has been chosen, as further illustrated in
Section 3.3 Because of this, link-local multicast communications can Figure 4. Because of this, link-local multicast communications can
happen only within a single Bluetooth LE connection, and thus 6LN-to- happen only within a single Bluetooth LE connection, and thus 6LN-to-
6LN communications using link-local addresses are not possible. 6LNs 6LN communications using link-local addresses are not possible. 6LNs
connected to the same 6LBR have to communicate with each other by connected to the same 6LBR have to communicate with each other by
using the shared prefix used on the subnet. The 6LBR ensures address 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 collisions do not occur (see Section 3.2.3) and forwards packets sent
by one 6LN to another. by one 6LN to another.
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 individual link. The 6LBR is acting as
router and forwarding packets between 6LNs and to and from Internet.
/
.---------------. /
/ 6LN \ /
/ \ \ /
| \ | /
| 6LN ----------- 6LBR ----- | Internet
| <--Link--> / | \
\ / / \
\ 6LN / \
'---------------' \
\
<------ Subnet -----><-- IPv6 connection -->
to Internet
Figure 4: Bluetooth LE network connected to the Internet
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 consist of a single subnet with multiple links,
where 6LBR is at central routing packets between 6LNs. In simplest
case the isolated network has one 6LBR and one 6LN.
.-------------------.
/ \
/ 6LN 6LN \
/ \ / \
| \ / |
| 6LN --- 6LBR --- 6LN |
| / \ |
\ / \ /
\ 6LN 6LN /
\ /
'-------------------'
<--------- Subnet ---------->
Figure 5: Isolated Bluetooth LE network
3.2.2. Stateless address autoconfiguration 3.2.2. Stateless address autoconfiguration
At network interface initialization, both 6LN and 6LBR SHALL generate At network interface initialization, both 6LN and 6LBR SHALL generate
and assign to the Bluetooth LE network interface IPv6 link-local and assign to the Bluetooth LE network interface IPv6 link-local
addresses [RFC4862] based on the 48-bit Bluetooth device addresses addresses [RFC4862] based on the 48-bit Bluetooth device addresses
(see Section 2.3) that were used for establishing the underlying (see Section 2.3) that were used for establishing the underlying
Bluetooth LE connection. Following the guidance of [RFC7136], a Bluetooth LE connection. Following the guidance of [RFC7136], a
64-bit Interface Identifier (IID) is formed from the 48-bit Bluetooth 64-bit Interface Identifier (IID) is formed from the 48-bit Bluetooth
device address by inserting two octets, with hexadecimal values of device address by inserting two octets, with hexadecimal values of
0xFF and 0xFE in the middle of the 48-bit Bluetooth device address as 0xFF and 0xFE in the middle of the 48-bit Bluetooth device address as
shown in Figure 4. In the Figure letter 'b' represents a bit from 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 the Bluetooth device address, copied as is without any changes on any
bit. This means that no bit in the IID indicates whether the bit. This means that no bit in the IID indicates whether the
underlying Bluetooth device address is public or random. underlying Bluetooth device address is public or random.
|0 1|1 3|3 4|4 6| |0 1|1 3|3 4|4 6|
|0 5|6 1|2 7|8 3| |0 5|6 1|2 7|8 3|
+----------------+----------------+----------------+----------------+ +----------------+----------------+----------------+----------------+
|bbbbbbbbbbbbbbbb|bbbbbbbb11111111|11111110bbbbbbbb|bbbbbbbbbbbbbbbb| |bbbbbbbbbbbbbbbb|bbbbbbbb11111111|11111110bbbbbbbb|bbbbbbbbbbbbbbbb|
+----------------+----------------+----------------+----------------+ +----------------+----------------+----------------+----------------+
Figure 4: Formation of IID from Bluetooth device adddress Figure 6: Formation of IID from Bluetooth device adddress
The IID is then prepended with the prefix fe80::/64, as described in The IID is then prepended with the prefix fe80::/64, as described in
RFC 4291 [RFC4291] and as depicted in Figure 5. The same link-local 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 address SHALL be used for the lifetime of the Bluetooth LE L2CAP
channel. (After a Bluetooth LE logical link has been established, it channel. (After a Bluetooth LE logical link has been established, it
is referenced with a Connection Handle in HCI. Thus possibly is referenced with a Connection Handle in HCI. Thus possibly
changing device addresses do not impact data flows within existing changing device addresses do not impact data flows within existing
L2CAP channels. Hence there is no need to change IPv6 link-local L2CAP channels. Hence there is no need to change IPv6 link-local
addresses even if devices change their random device addresses during addresses even if devices change their random device addresses during
L2CAP channel lifetime). L2CAP channel lifetime).
10 bits 54 bits 64 bits 10 bits 54 bits 64 bits
+----------+-----------------+----------------------+ +----------+-----------------+----------------------+
|1111111010| zeros | Interface Identifier | |1111111010| zeros | Interface Identifier |
+----------+-----------------+----------------------+ +----------+-----------------+----------------------+
Figure 5: IPv6 link-local address in Bluetooth LE Figure 7: IPv6 link-local address in Bluetooth LE
A 6LN MUST join the all-nodes multicast address. There is no need 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 for 6LN to join the solicited-node multicast address, since 6LBR will
know device addresses and hence link-local addresses of all connected know device addresses and hence link-local addresses of all connected
6LNs. The 6LBR will ensure no two devices with the same Bluetooth LE 6LNs. The 6LBR will ensure no two devices with the same Bluetooth LE
device address are connected at the same time. Detection of device address are connected at the same time. Detection of
duplicate link-local addresses is performed by the process on the duplicate link-local addresses is performed by the process on the
6LBR responsible for the discovery of IP-enabled Bluetooth LE nodes 6LBR responsible for the discovery of IP-enabled Bluetooth LE nodes
and for starting Bluetooth LE connection establishment procedures. and for starting Bluetooth LE connection establishment procedures.
This approach increases the complexity of 6LBR, but reduces power This approach increases the complexity of 6LBR, but reduces power
consumption on both 6LN and 6LBR in the link establishment phase by consumption on both 6LN and 6LBR in the link establishment phase by
reducing the number of mandatory packet transmissions. reducing the number of mandatory packet transmissions.
After link-local address configuration, the 6LN sends Router After link-local address configuration, the 6LN sends Router
Solicitation messages as described in [RFC4861] Section 6.3.7. Solicitation messages as described in [RFC4861] Section 6.3.7.
For non-link-local addresses a 64-bit IID MAY be formed by utilizing For non-link-local addresses, 6LNs SHOULD NOT be configured to embed
the 48-bit Bluetooth device address. A 6LN can also use a randomly the Bluetooth device address in the IID by default. Alternative
generated IID (see Section 3.2.3), for example, as discussed in schemes such as Cryptographically Generated Addresses (CGA)
[I-D.ietf-6man-default-iids], or use alternative schemes such as [RFC3972], privacy extensions [RFC4941], Hash-Based Addresses (HBA,
Cryptographically Generated Addresses (CGA) [RFC3972], privacy [RFC5535]), DHCPv6 [RFC3315], or static, semantically opaque addreses
extensions [RFC4941], Hash-Based Addresses (HBA, [RFC5535]), or [RFC7217] SHOULD be used by default. In situations where the
DHCPv6 [RFC3315]. The non-link-local addresses that a 6LN generates Bluetooth device address is known to be randomly generated and/or the
MUST be registered with the 6LBR as described in Section 3.2.3. 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 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, Bluetooth LE network is out of scope of this document, but can be,
for example, accomplished via DHCPv6 Prefix Delegation [RFC3633] or for example, accomplished via DHCPv6 Prefix Delegation [RFC3633] or
by using Unique Local IPv6 Unicast Addresses (ULA) [RFC4193]. Due to by using Unique Local IPv6 Unicast Addresses (ULA) [RFC4193]. Due to
the link model of the Bluetooth LE (see Section 3.2.1) the 6LBR MUST 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 set the "on-link" flag (L) to zero in the Prefix Information Option
in Neighbor Discovery messages[RFC4861] (see Section 3.2.2). This in Neighbor Discovery messages[RFC4861] (see Section 3.2.3). This
will cause 6LNs to always send packets to the 6LBR, including the will cause 6LNs to always send packets to the 6LBR, including the
case when the destination is another 6LN using the same prefix. case when the destination is another 6LN using the same prefix.
3.2.3. Neighbor discovery 3.2.3. Neighbor discovery
'Neighbor Discovery Optimization for IPv6 over Low-Power Wireless 'Neighbor Discovery Optimization for IPv6 over Low-Power Wireless
Personal Area Networks (6LoWPANs)' [RFC6775] describes the neighbor Personal Area Networks (6LoWPANs)' [RFC6775] describes the neighbor
discovery approach as adapted for use in several 6LoWPAN topologies, discovery approach as adapted for use in several 6LoWPAN topologies,
including the mesh topology. Bluetooth LE does not support mesh including the mesh topology. Bluetooth LE does not support mesh
networks and hence only those aspects that apply to a star topology networks and hence only those aspects that apply to a star topology
skipping to change at page 11, line 48 skipping to change at page 13, line 13
decrease (see Section 3.2.4). decrease (see Section 3.2.4).
2. For sending Router Solicitations and processing Router 2. For sending Router Solicitations and processing Router
Advertisements the Bluetooth LE 6LNs MUST, respectively, follow Advertisements the Bluetooth LE 6LNs MUST, respectively, follow
Sections 5.3 and 5.4 of the [RFC6775]. Sections 5.3 and 5.4 of the [RFC6775].
3.2.4. Header compression 3.2.4. Header compression
Header compression as defined in RFC 6282 [RFC6282], which specifies Header compression as defined in RFC 6282 [RFC6282], which specifies
the compression format for IPv6 datagrams on top of IEEE 802.15.4, is the compression format for IPv6 datagrams on top of IEEE 802.15.4, is
REQUIRED in this document as the basis for IPv6 header compression on REQUIRED as the basis for IPv6 header compression on top of Bluetooth
top of Bluetooth LE. All headers MUST be compressed according to RFC LE. All headers MUST be compressed according to RFC 6282 [RFC6282]
6282 [RFC6282] encoding formats. encoding formats.
The Bluetooth LE's star topology structure and ARO can be exploited The Bluetooth LE's star topology structure and ARO can be exploited
in order to provide a mechanism for address compression. The in order to provide a mechanism for address compression. The
following text describes the principles of IPv6 address compression following text describes the principles of IPv6 address compression
on top of Bluetooth LE. on top of Bluetooth LE.
The ARO option requires use of an EUI-64 identifier [RFC6775]. In The ARO option requires use of an EUI-64 identifier [RFC6775]. In
the case of Bluetooth LE, the field SHALL be filled with the 48-bit 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 device address used by the Bluetooth LE node converted into 64-bit
Modified EUI-64 format [RFC4291]. Modified EUI-64 format [RFC4291].
To enable efficient header compression, when the 6LBR sends a Router To enable efficient header compression, when the 6LBR sends a Router
Advertisement it MUST include a 6LoWPAN Context Option (6CO) Advertisement it MUST include a 6LoWPAN Context Option (6CO)
[RFC6775] matching each address prefix advertised via a Prefix [RFC6775] matching each address prefix advertised via a Prefix
Information Option (PIO) [RFC4861] for use in stateless address Information Option (PIO) [RFC4861] for use in stateless address
autoconfiguration. autoconfiguration.
When a 6LN is sending a packet to or through a 6LBR, it MUST fully When a 6LN is sending a packet to a 6LBR, it MUST fully elide the
elide the source address if it is a link-local address. A non-link- source address if it is a link-local address. For other packets to
local source address 6LN has registered with ARO to the 6LBR for the or through a 6LBR with a non-link-local source address that the 6LN
indicated prefix MUST be fully elided if the source address is the has registered with ARO to the 6LBR for the indicated prefix, the
latest address 6LN has registered for the indicated prefix. If a source address MUST be fully elided if it is the latest address that
source non-link-local address is not the latest registered, then the the 6LN has registered for the indicated prefix. If a source non-
64-bits of the IID SHALL be fully carried in-line (SAM=01) or if the link-local address is not the latest registered, then the 64-bits of
first 48-bits of the IID match with the latest registered address, the IID SHALL be fully carried in-line (SAM=01) or if the first
then the last 16-bits of the IID SHALL be carried in-line (SAM=10). 48-bits of the IID match with the latest registered address, then the
That is, if SAC=0 and SAM=11 the 6LN MUST be using the link-local last 16-bits of the IID SHALL be carried in-line (SAM=10). That is,
IPv6 address derived from Bluetooth LE device address, and if SAC=1 if SAC=0 and SAM=11 the 6LN MUST be using the link-local IPv6 address
and SAM=11 the 6LN MUST have registered the source IPv6 address with derived from Bluetooth LE device address, and if SAC=1 and SAM=11 the
the prefix related to the compression context and the 6LN MUST be 6LN MUST have registered the source IPv6 address with the prefix
referring to the latest registered address related to the compression related to the compression context and the 6LN MUST be referring to
context. The IPv6 address MUST be considered to be registered only the latest registered address related to the compression context.
after the 6LBR has sent a Neighbor Advertisement with an ARO having The IPv6 address MUST be considered to be registered only after the
its status field set to success. The destination IPv6 address MUST 6LBR has sent a Neighbor Advertisement with an ARO having its status
be fully elided if the destination address is 6LBR's link-local- field set to success. The destination IPv6 address MUST be fully
address based on the 6LBR's Bluetooth device address (DAC=0, DAM=11). elided if the destination address is 6LBR's link-local-address based
The destination IPv6 address MUST be fully or partially elided if on the 6LBR's Bluetooth device address (DAC=0, DAM=11). The
context has been set up for the destination address. For example, destination IPv6 address MUST be fully or partially elided if context
DAC=0 and DAM=01 when destination prefix is link-local, and DAC=1 and has been set up for the destination address. For example, DAC=0 and
DAM=01 if compression context has been configured for the destination DAM=01 when destination prefix is link-local, and DAC=1 and DAM=01 if
prefix used. compression context has been configured for the destination prefix
used.
When a 6LBR is transmitting packets to a 6LN, it MUST fully elide the 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 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 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 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 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 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 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 the destination address is the latest registered by the 6LN with ARO
for the indicated context (DAC=1, DAM=11). If the destination for the indicated context (DAC=1, DAM=11). If the destination
skipping to change at page 14, line 29 skipping to change at page 15, line 41
SAM=11 or DAC=1/DAM=11. SAM=11 or DAC=1/DAM=11.
2) The 6LN registers second address 2001:db8::1111:2222:3333:5555 to 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 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 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/ 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 DAM=10, as the first 112 bits of the address are the same between the
first and the second registered addresses. first and the second registered addresses.
3) Expiration of registration time for the first or the second 3) Expiration of registration time for the first or the second
address has no impact on the compression. Hence even if most address has no impact on the compression. Hence even if the most
recently registered address expires, the first address can only be recently registered address expires, the first address can only be
partially elided (SAC=1/SAM=10, DAC=1/DAM=10). The 6LN can register 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 a new address, or re-register an expired address, to become able to
again fully elide an address. again fully elide an address.
3.2.5. Unicast and Multicast address mapping 3.2.5. Unicast and Multicast address mapping
The Bluetooth LE link layer does not support multicast. Hence The Bluetooth LE link layer does not support multicast. Hence
traffic is always unicast between two Bluetooth LE nodes. Even in traffic is always unicast between two Bluetooth LE nodes. Even in
the case where a 6LBR is attached to multiple 6LNs, the 6LBR cannot the case where a 6LBR is attached to multiple 6LNs, the 6LBR cannot
do a multicast to all the connected 6LNs. If the 6LBR needs to send do a multicast to all the connected 6LNs. If the 6LBR needs to send
a multicast packet to all its 6LNs, it has to replicate the packet a multicast packet to all its 6LNs, it has to replicate the packet
and unicast it on each link. However, this may not be energy- and unicast it on each link. However, this may not be energy-
efficient and particular care must be taken if the central is efficient and particular care must be taken if the central is
battery-powered. In the opposite direction, a 6LN always has to send battery-powered. To further conserve power, the 6LBR MUST keep track
packets to or through 6LBR. Hence, when a 6LN needs to transmit an of multicast listeners at Bluetooth LE link level granularity (not at
IPv6 multicast packet, the 6LN will unicast the corresponding 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 6LBR. Hence, when a 6LN needs to transmit
an IPv6 multicast packet, the 6LN will unicast the corresponding
Bluetooth LE packet to the 6LBR. Bluetooth LE packet to the 6LBR.
3.3. Subnets and Internet connectivity scenarios
In a typical scenario, the Bluetooth LE network is connected to the
Internet as shown in the Figure 6. In this scenario, the Bluetooth
LE star is deployed as one subnet, using one /64 IPv6 prefix, with
each spoke representing individual link. The 6LBR is acting as
router and forwarding packets between 6LNs and to and from Internet.
/
.---------------. /
/ 6LN \ /
/ \ \ /
| \ | /
| 6LN ----------- 6LBR ----- | Internet
| <--Link--> / | \
\ / / \
\ 6LN / \
'---------------' \
\
<------ Subnet -----><-- IPv6 connection -->
to Internet
Figure 6: Bluetooth LE network connected to the Internet
In some scenarios, the Bluetooth LE network may transiently or
permanently be an isolated network as shown in the Figure 7. In this
case the whole star consist of a single subnet with multiple links,
where 6LBR is at central routing packets between 6LNs.
.-------------------.
/ \
/ 6LN 6LN \
/ \ / \
| \ / |
| 6LN --- 6LBR --- 6LN |
| / \ |
\ / \ /
\ 6LN 6LN /
\ /
'-------------------'
<--------- Subnet ---------->
Figure 7: Isolated Bluetooth LE network
It is also possible to have point-to-point connection between two
6LNs, one of which being central and another being peripheral.
Similarly, it is possible to have point-to-point connections between
two 6LBRs, one of which being central and another being peripheral.
At this point in time mesh networking with Bluetooth LE is not
specified.
4. IANA Considerations 4. IANA Considerations
There are no IANA considerations related to this document. There are no IANA considerations related to this document.
5. Security Considerations 5. Security Considerations
The transmission of IPv6 over Bluetooth LE links has similar The transmission of IPv6 over Bluetooth LE links has similar
requirements and concerns for security as for IEEE 802.15.4. requirements and concerns for security as for IEEE 802.15.4.
Bluetooth LE Link Layer security considerations are covered by the Bluetooth LE Link Layer security considerations are covered by the
IPSP [IPSP]. IPSP [IPSP].
skipping to change at page 16, line 37 skipping to change at page 16, line 41
exploit this functionality when it is available. (Note: CCM does not exploit this functionality when it is available. (Note: CCM does not
consume octets from the maximum per-packet L2CAP data size, since the 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 link layer data unit has a specific field for them when they are
used.) used.)
Key management in Bluetooth LE is provided by the Security Manager Key management in Bluetooth LE is provided by the Security Manager
Protocol (SMP), as defined in [BTCorev4.1]. Protocol (SMP), as defined in [BTCorev4.1].
The Direct Test Mode offers two setup alternatives: with and without The Direct Test Mode offers two setup alternatives: with and without
accessible HCI. In designs with accessible HCI, the so called upper accessible HCI. In designs with accessible HCI, the so called upper
tester communicates through the HCI (which may be supported by UART, tester communicates through the HCI (which may be supported by
USB and Secure Digital transports), with the Physical and Link Layers Universal Asynchronous Receiver Transmitter (UART), Universal Serial
of the Bluetooth LE device under test. In designs without accessible Bus (USB) and Secure Digital transports), with the Physical and Link
HCI, the upper tester communicates with the device under test through Layers of the Bluetooth LE device under test. In designs without
a two-wire UART interface. The Bluetooth specification does not accessible HCI, the upper tester communicates with the device under
provide security mechanisms for the communication between the upper test through a two-wire UART interface. The Bluetooth specification
tester and the device under test in either case. Nevertheless, an does not provide security mechanisms for the communication between
attacker needs to physically connect a device (via one of the wired the upper tester and the device under test in either case.
HCI types) to the device under test to be able to interact with the Nevertheless, an attacker needs to physically connect a device (via
latter. one of the wired HCI types) to the device under test to be able to
interact with the latter.
The IPv6 link-local address configuration described in Section 3.2.2 The IPv6 link-local address configuration described in Section 3.2.2
strictly binds the privacy level of IPv6 link-local address to the only reveals information about the 6LN to the 6LBR that the 6LBR
privacy level device has selected for the Bluetooth LE. This means already knows from the link layer connection. This means that a
that a device using Bluetooth privacy features will retain the same device using Bluetooth privacy features reveals the same information
level of privacy with generated IPv6 link-local addresses. in its IPv6 link-local addresses as in its device addresses.
Respectively, device not using privacy at Bluetooth level will not Respectively, device not using privacy at Bluetooth level will not
have privacy at IPv6 link-local address either. For non-link local have privacy at IPv6 link-local address either. For non-link local
addresses implementations have a choice to support, for example, addresses implementations have a choice to support, for example,
[I-D.ietf-6man-default-iids], [RFC3972], [RFC4941] or [RFC5535]. [I-D.ietf-6man-default-iids], [RFC3315], [RFC3972], [RFC4941],
[RFC5535], or [RFC7217].
A malicious 6LN may attempt to perform a denial of service attacks on A malicious 6LN may attempt to perform a denial of service attack on
the Bluetooth LE network, for example, by flooding packets. This the Bluetooth LE network, for example, by flooding packets. This
sort of attack is mitigated by the fact that link-local multicast is 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 not bridged between Bluetooth LE links and by 6LBR being able to rate
limit packets sent by each 6LN by making smart use of Bluetooth LE limit packets sent by each 6LN by making smart use of Bluetooth LE
L2CAP credit-based flow control mechanism. L2CAP credit-based flow control mechanism.
6. Additional contributors 6. Additional contributors
Kanji Kerai, Jari Mutikainen, David Canfeng-Chen and Minjun Xi from Kanji Kerai, Jari Mutikainen, David Canfeng-Chen and Minjun Xi from
Nokia have contributed significantly to this document. Nokia have contributed significantly to this document.
7. Acknowledgements 7. Acknowledgements
The Bluetooth, Bluetooth Smart and Bluetooth Smart Ready marks are The Bluetooth, Bluetooth Smart and Bluetooth Smart Ready marks are
registred trademarks owned by Bluetooth SIG, Inc. registred trademarks owned by Bluetooth SIG, Inc.
Samita Chakrabarti, Brian Haberman, Marcel De Kogel, Jouni Korhonen, Carsten Bormann, Samita Chakrabarti, Niclas Comstedt, Alissa Cooper,
Erik Nordmark, Erik Rivard, Dave Thaler, Pascal Thubert, Xavi Elwyn Davies, Brian Haberman, Marcel De Kogel, Jouni Korhonen, Chris
Vilajosana and Victor Zhodzishsky have provided valuable feedback for Lonvick, Erik Nordmark, Erik Rivard, Dave Thaler, Pascal Thubert,
this draft. Xavi Vilajosana and Victor Zhodzishsky have provided valuable
feedback for this draft.
Authors would like to give special acknowledgements for Krishna Authors would like to give special acknowledgements for Krishna
Shingala, Frank Berntsen, and Bluetooth SIG's Internet Working Group Shingala, Frank Berntsen, and Bluetooth SIG's Internet Working Group
for providing significant feedback and improvement proposals for this for providing significant feedback and improvement proposals for this
document. document.
8. References 8. References
8.1. Normative References 8.1. Normative References
skipping to change at page 18, line 9 skipping to change at page 18, line 14
[IPSP] Bluetooth Special Interest Group, "Bluetooth Internet [IPSP] Bluetooth Special Interest Group, "Bluetooth Internet
Protocol Support Profile Specification Version 1.0.0", Protocol Support Profile Specification Version 1.0.0",
December 2014, <https://www.bluetooth.org/en- December 2014, <https://www.bluetooth.org/en-
us/specification/adopted-specifications>. us/specification/adopted-specifications>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing
Architecture", RFC 4291, February 2006. Architecture", RFC 4291, DOI 10.17487/RFC4291, February
2006, <http://www.rfc-editor.org/info/rfc4291>.
[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
"Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,
September 2007. DOI 10.17487/RFC4861, September 2007,
<http://www.rfc-editor.org/info/rfc4861>.
[RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless
Address Autoconfiguration", RFC 4862, September 2007. Address Autoconfiguration", RFC 4862,
DOI 10.17487/RFC4862, September 2007,
<http://www.rfc-editor.org/info/rfc4862>.
[RFC6282] Hui, J. and P. Thubert, "Compression Format for IPv6 [RFC6282] Hui, J., Ed. and P. Thubert, "Compression Format for IPv6
Datagrams over IEEE 802.15.4-Based Networks", RFC 6282, Datagrams over IEEE 802.15.4-Based Networks", RFC 6282,
September 2011. DOI 10.17487/RFC6282, September 2011,
<http://www.rfc-editor.org/info/rfc6282>.
[RFC6775] Shelby, Z., Chakrabarti, S., Nordmark, E., and C. Bormann, [RFC6775] Shelby, Z., Ed., Chakrabarti, S., Nordmark, E., and C.
"Neighbor Discovery Optimization for IPv6 over Low-Power Bormann, "Neighbor Discovery Optimization for IPv6 over
Wireless Personal Area Networks (6LoWPANs)", RFC 6775, Low-Power Wireless Personal Area Networks (6LoWPANs)",
November 2012. RFC 6775, DOI 10.17487/RFC6775, November 2012,
<http://www.rfc-editor.org/info/rfc6775>.
[RFC7136] Carpenter, B. and S. Jiang, "Significance of IPv6 [RFC7136] Carpenter, B. and S. Jiang, "Significance of IPv6
Interface Identifiers", RFC 7136, February 2014. Interface Identifiers", RFC 7136, DOI 10.17487/RFC7136,
February 2014, <http://www.rfc-editor.org/info/rfc7136>.
8.2. Informative References 8.2. Informative References
[fifteendotfour] [fifteendotfour]
IEEE Computer Society, "IEEE Std. 802.15.4-2011 IEEE IEEE Computer Society, "IEEE Std. 802.15.4-2011 IEEE
Standard for Local and metropolitan area networks--Part Standard for Local and metropolitan area networks--Part
15.4: Low-Rate Wireless Personal Area Networks (LR- 15.4: Low-Rate Wireless Personal Area Networks (LR-
WPANs)", June 2011. WPANs)", June 2011.
[I-D.ietf-6man-default-iids] [I-D.ietf-6man-default-iids]
Gont, F., Cooper, A., Thaler, D., and S. LIU, Gont, F., Cooper, A., Thaler, D., and S. LIU,
"Recommendation on Stable IPv6 Interface Identifiers", "Recommendation on Stable IPv6 Interface Identifiers",
draft-ietf-6man-default-iids-03 (work in progress), May draft-ietf-6man-default-iids-05 (work in progress), July
2015. 2015.
[IEEE802-2001] [IEEE802-2001]
Institute of Electrical and Electronics Engineers (IEEE), Institute of Electrical and Electronics Engineers (IEEE),
"IEEE 802-2001 Standard for Local and Metropolitan Area "IEEE 802-2001 Standard for Local and Metropolitan Area
Networks: Overview and Architecture", 2002. Networks: Overview and Architecture", 2002.
[RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., [RFC3315] Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins,
and M. Carney, "Dynamic Host Configuration Protocol for C., and M. Carney, "Dynamic Host Configuration Protocol
IPv6 (DHCPv6)", RFC 3315, July 2003. for IPv6 (DHCPv6)", RFC 3315, DOI 10.17487/RFC3315, July
2003, <http://www.rfc-editor.org/info/rfc3315>.
[RFC3610] Whiting, D., Housley, R., and N. Ferguson, "Counter with [RFC3610] Whiting, D., Housley, R., and N. Ferguson, "Counter with
CBC-MAC (CCM)", RFC 3610, September 2003. CBC-MAC (CCM)", RFC 3610, DOI 10.17487/RFC3610, September
2003, <http://www.rfc-editor.org/info/rfc3610>.
[RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic [RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic
Host Configuration Protocol (DHCP) version 6", RFC 3633, Host Configuration Protocol (DHCP) version 6", RFC 3633,
December 2003. DOI 10.17487/RFC3633, December 2003,
<http://www.rfc-editor.org/info/rfc3633>.
[RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)", [RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)",
RFC 3972, March 2005. RFC 3972, DOI 10.17487/RFC3972, March 2005,
<http://www.rfc-editor.org/info/rfc3972>.
[RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast
Addresses", RFC 4193, October 2005. Addresses", RFC 4193, DOI 10.17487/RFC4193, October 2005,
<http://www.rfc-editor.org/info/rfc4193>.
[RFC4903] Thaler, D., "Multi-Link Subnet Issues", RFC 4903, June [RFC4903] Thaler, D., "Multi-Link Subnet Issues", RFC 4903,
2007. DOI 10.17487/RFC4903, June 2007,
<http://www.rfc-editor.org/info/rfc4903>.
[RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy [RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy
Extensions for Stateless Address Autoconfiguration in Extensions for Stateless Address Autoconfiguration in
IPv6", RFC 4941, September 2007. IPv6", RFC 4941, DOI 10.17487/RFC4941, September 2007,
<http://www.rfc-editor.org/info/rfc4941>.
[RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler, [RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler,
"Transmission of IPv6 Packets over IEEE 802.15.4 "Transmission of IPv6 Packets over IEEE 802.15.4
Networks", RFC 4944, September 2007. Networks", RFC 4944, DOI 10.17487/RFC4944, September 2007,
<http://www.rfc-editor.org/info/rfc4944>.
[RFC5535] Bagnulo, M., "Hash-Based Addresses (HBA)", RFC 5535, June [RFC5535] Bagnulo, M., "Hash-Based Addresses (HBA)", RFC 5535,
2009. DOI 10.17487/RFC5535, June 2009,
<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>.
Authors' Addresses Authors' Addresses
Johanna Nieminen Johanna Nieminen
Nokia Nokia
Email: johannamaria.nieminen@gmail.com Email: johannamaria.nieminen@gmail.com
Teemu Savolainen Teemu Savolainen
Nokia Nokia
 End of changes. 43 change blocks. 
158 lines changed or deleted 181 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/