< draft-ietf-6lo-btle-12.txt   draft-ietf-6lo-btle-13.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: November 16, 2015 Nokia Expires: November 23, 2015 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
May 15, 2015 May 22, 2015
IPv6 over BLUETOOTH(R) Low Energy IPv6 over BLUETOOTH(R) Low Energy
draft-ietf-6lo-btle-12 draft-ietf-6lo-btle-13
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 47 skipping to change at page 1, line 47
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on November 16, 2015. This Internet-Draft will expire on November 23, 2015.
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
skipping to change at page 2, line 28 skipping to change at page 2, line 28
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 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 . . . . . . . . . . . . . 5 2.3. Bluetooth LE device addressing . . . . . . . . . . . . . 5
2.4. Bluetooth LE packets sizes and MTU . . . . . . . . . . . 5 2.4. Bluetooth LE packets 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 . . . . . . . . . . . . . . . . . . . . . . . 7 3.2. Link model . . . . . . . . . . . . . . . . . . . . . . . 7
3.2.1. Stateless address autoconfiguration . . . . . . . . . 8 3.2.1. Stateless address autoconfiguration . . . . . . . . . 8
3.2.2. Neighbor discovery . . . . . . . . . . . . . . . . . 10 3.2.2. Neighbor discovery . . . . . . . . . . . . . . . . . 10
3.2.3. Header compression . . . . . . . . . . . . . . . . . 10 3.2.3. Header compression . . . . . . . . . . . . . . . . . 11
3.2.3.1. Remote destination example . . . . . . . . . . . 12 3.2.3.1. Remote destination example . . . . . . . . . . . 12
3.2.3.2. Example of registration of multiple-addresses . . 13 3.2.3.2. Example of registration of multiple-addresses . . 13
3.2.4. Unicast and Multicast address mapping . . . . . . . . 13 3.2.4. Unicast and Multicast address mapping . . . . . . . . 13
3.3. Subnets and Internet connectivity scenarios . . . . . . . 13 3.3. Subnets and Internet connectivity scenarios . . . . . . . 14
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
5. Security Considerations . . . . . . . . . . . . . . . . . . . 15 5. Security Considerations . . . . . . . . . . . . . . . . . . . 15
6. Additional contributors . . . . . . . . . . . . . . . . . . . 15 6. Additional contributors . . . . . . . . . . . . . . . . . . . 16
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 15 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 16
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 16
8.1. Normative References . . . . . . . . . . . . . . . . . . 16 8.1. Normative References . . . . . . . . . . . . . . . . . . 16
8.2. Informative References . . . . . . . . . . . . . . . . . 16 8.2. Informative References . . . . . . . . . . . . . . . . . 17
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18
1. Introduction 1. Introduction
Bluetooth low energy (LE) is a radio technology targeted for devices Bluetooth low energy (LE) is a radio technology targeted for devices
that operate with coin cell batteries or minimalistic power sources, that operate with 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,
such as health monitors, environmental sensing, proximity such as health monitors, environmental sensing, proximity
applications and many others. applications and many others.
Considering the potential for the exponential growth in the number of Considering the potential for the exponential growth in the number of
sensors and Internet connected devices, IPv6 is an ideal protocol due sensors and Internet connected devices, IPv6 is an ideal protocol due
to the large address space it provides. In addition, IPv6 provides to the large address space it provides. In addition, IPv6 provides
tools for stateless address autoconfiguration, which is particularly tools for stateless address autoconfiguration, which is particularly
suitable for sensor network applications and nodes which have very suitable for sensor network applications and nodes which have very
limited processing power or lack a full-fledged operating system. limited processing power or lack a full-fledged operating system.
RFC 4944 [RFC4944] specifies the transmission of IPv6 over IEEE RFCs 4944, 6282, and 6775 [RFC4944][RFC6282][RFC6775] specify the
802.15.4. The Bluetooth LE link in many respects has similar transmission of IPv6 over IEEE 802.15.4. The Bluetooth LE link in
characteristics to that of IEEE 802.15.4. Many of the mechanisms many respects has similar characteristics to that of IEEE 802.15.4
defined in the RFC 4944 can be applied to the transmission of IPv6 on and many of the mechanisms defined for the IPv6 over IEEE 802.15.4
Bluetooth LE links. This document specifies the details of IPv6 can be applied to the transmission of IPv6 on Bluetooth LE links.
transmission over Bluetooth LE links. This document specifies the details of IPv6 transmission over
Bluetooth LE links.
1.1. Terminology and Requirements Language 1.1. Terminology and Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119]. document are to be interpreted as described in RFC 2119 [RFC2119].
The terms 6LN, 6LR and 6LBR are defined as in [RFC6775], with an The terms 6LN, 6LR and 6LBR are defined as in [RFC6775], with an
addition that Bluetooth LE central and Bluetooth LE peripheral (see addition that Bluetooth LE central and Bluetooth LE peripheral (see
Section 2.2) can both be either 6LN or 6LBR. Section 2.2) can both be either 6LN or 6LBR.
skipping to change at page 4, line 17 skipping to change at page 4, line 17
have the low-energy functionality of Bluetooth. Bluetooth LE will have the low-energy functionality of Bluetooth. Bluetooth LE will
also be included in many different types of accessories that also be included in many different types of accessories that
collaborate with mobile devices such as phones, tablets and notebook collaborate with mobile devices such as phones, tablets and notebook
computers. An example of a use case for a Bluetooth LE accessory is computers. An example of a use case for a Bluetooth LE accessory is
a heart rate monitor that sends data via the mobile phone to a server a heart rate monitor that sends data via the mobile phone to a server
on the Internet. on the Internet.
2.1. Bluetooth LE stack 2.1. Bluetooth LE stack
The lower layer of the Bluetooth LE stack consists of the Physical The lower layer of the Bluetooth LE stack consists of the Physical
(PHY) and the Link Layer (LL). The Physical Layer transmits and (PHY), the Link Layer (LL), and a test interface called the Direct
receives the actual packets. The Link Layer is responsible for Test Mode (DTM). The Physical Layer transmits and receives the
providing medium access, connection establishment, error control and actual packets. The Link Layer is responsible for providing medium
flow control. The upper layer consists of the Logical Link Control access, connection establishment, error control and flow control.
and Adaptation Protocol (L2CAP), Attribute Protocol (ATT), Generic The Direct Test Mode is only used for testing purposes. The upper
layer consists of the Logical Link Control and Adaptation Protocol
(L2CAP), Attribute Protocol (ATT), Security Manager (SM), Generic
Attribute Profile (GATT) and Generic Access Profile (GAP) as shown in Attribute Profile (GATT) and Generic Access Profile (GAP) as shown in
Figure 1. The device internal Host Controller Interface (HCI) Figure 1. The device internal Host Controller Interface (HCI)
separates the lower layers, often implemented in the Bluetooth separates the lower layers, often implemented in the Bluetooth
controller, from higher layers, often implemented in the host stack. controller, from higher layers, often implemented in the host stack.
GATT and Bluetooth LE profiles together enable the creation of GATT and Bluetooth LE profiles together enable the creation of
applications in a standardized way without using IP. L2CAP provides applications in a standardized way without using IP. L2CAP provides
multiplexing capability by multiplexing the data channels from the multiplexing capability by multiplexing the data channels from the
above layers. L2CAP also provides fragmentation and reassembly for above layers. L2CAP also provides fragmentation and reassembly for
large data packets. large data packets. The Security Manager defines a protocol and
mechanisms for pairing, key distribution and a security toolbox for
the Bluetooth LE device.
+-------------------------------------------------+ +-------------------------------------------------+
| Applications | | Applications |
+---------------------------------------+---------+ +---------------------------------------+---------+
| Generic Attribute Profile | Generic | | Generic Attribute Profile | Generic |
+--------------------+------------------+ Access | +--------------------+------------------+ Access |
| Attribute Protocol | Security Manager | Profile | | Attribute Protocol | Security Manager | Profile |
+--------------------+------------------+---------+ +--------------------+------------------+---------+
| Logical Link Control and Adaptation Protocol | | Logical Link Control and Adaptation Protocol |
- - -+-----------------------+-------------------------+- - - HCI - - -+-----------------------+-------------------------+- - - HCI
| Link Layer | Direct Test Mode | | Link Layer | Direct Test Mode |
+-------------------------------------------------+ +-------------------------------------------------+
| Physical Layer | | Physical Layer |
+-------------------------------------------------+ +-------------------------------------------------+
Figure 1: Bluetooth LE Protocol Stack Figure 1: Bluetooth LE Protocol Stack
As shown in Section 3.1, IPv6 over Bluetooth LE requires an adapted
6LoWPAN layer which runs on top of Bluetooth LE L2CAP.
2.2. Link layer roles and topology 2.2. Link layer roles and topology
Bluetooth LE defines two GAP roles of relevance herein: the Bluetooth Bluetooth LE defines two GAP roles of relevance herein: the Bluetooth
LE central role and the Bluetooth LE peripheral role. A device in LE central role and the Bluetooth LE peripheral role. A device in
the central role, which is called central from now on, has the central role, which is called central from now on, has
traditionally been able to manage multiple simultaneous connections traditionally been able to manage multiple simultaneous connections
with a number of devices in the peripheral role, called peripherals with a number of devices in the peripheral role, called peripherals
from now on. A peripheral is commonly connected to a single central, from now on. A peripheral is commonly connected to a single central,
but since Bluetooth 4.1 can also connect to multiple centrals. In but since Bluetooth 4.1 can also connect to multiple centrals. In
this document for IPv6 networking purposes the Bluetooth LE network this document for IPv6 networking purposes the Bluetooth LE network
skipping to change at page 5, line 29 skipping to change at page 5, line 32
LE. LE.
Peripheral --. .-- Peripheral Peripheral --. .-- Peripheral
\ / \ /
Peripheral ---- Central ---- Peripheral Peripheral ---- Central ---- Peripheral
/ \ / \
Peripheral --' '-- Peripheral Peripheral --' '-- Peripheral
Figure 2: Bluetooth LE Star Topology Figure 2: Bluetooth LE Star Topology
In Bluetooth LE, direct communication only takes place between a In Bluetooth LE, direct wireless communication only takes place
central and a peripheral. This means that inherently the Bluetooth between a central and a peripheral. This means that inherently the
LE star represents a hub and spokes link model. 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.
2.3. Bluetooth LE device addressing 2.3. Bluetooth LE device addressing
Every Bluetooth LE device is identified by a 48-bit device address. Every Bluetooth LE device is identified by a 48-bit device address.
The Bluetooth specification describes the device address of a The Bluetooth specification describes the device address of a
Bluetooth LE device as:"Devices are identified using a device Bluetooth LE device as:"Devices are identified using a device
address. Device addresses may be either a public device address or a address. Device addresses may be either a public device address or a
random device address." [BTCorev4.1]. The public device addresses random device address." [BTCorev4.1]. The public device addresses
are based on the IEEE 802-2001 standard [IEEE802-2001]. The random are based on the IEEE 802-2001 standard [IEEE802-2001]. The random
device addresses are generated as defined in the Bluetooth device addresses are generated as defined in the Bluetooth
skipping to change at page 6, line 30 skipping to change at page 6, line 36
functionality comprises of link-local IPv6 addresses and stateless functionality comprises of link-local IPv6 addresses and stateless
IPv6 address autoconfiguration (see Section 3.2.1), Neighbor IPv6 address autoconfiguration (see Section 3.2.1), Neighbor
Discovery (see Section 3.2.2) and header compression (see Discovery (see Section 3.2.2) and header compression (see
Section 3.2.3). Fragmentation features from 6LoWPAN standards are Section 3.2.3). Fragmentation features from 6LoWPAN standards are
not used due Bluetooth LE's link layer fragmentation support (see not used due Bluetooth LE's link layer fragmentation support (see
Section 2.4). Section 2.4).
A significant difference between IEEE 802.15.4 and Bluetooth LE is A significant difference between IEEE 802.15.4 and Bluetooth LE is
that the former supports both star and mesh topology (and requires a that the former supports both star and mesh topology (and requires a
routing protocol), whereas Bluetooth LE does not currently support routing protocol), whereas Bluetooth LE does not currently support
the formation of multihop networks at the link layer. 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.
In Bluetooth LE a central node is assumed to be less constrained than In Bluetooth LE a central node is assumed to be less constrained than
a peripheral node. Hence, in the primary deployment scenario central a peripheral node. Hence, in the primary deployment scenario central
and peripheral will act as 6LoWPAN Border Router (6LBR) and a 6LoWPAN and peripheral will act as 6LoWPAN Border Router (6LBR) and a 6LoWPAN
Node (6LN), respectively. Node (6LN), respectively.
Before any IP-layer communications can take place over Bluetooth LE, Before any IP-layer communications can take place over Bluetooth LE,
Bluetooth LE enabled nodes such as 6LNs and 6LBRs have to find each Bluetooth LE enabled nodes such as 6LNs and 6LBRs have to find each
other and establish a suitable link-layer connection. The discovery other and establish a suitable link-layer connection. The discovery
and Bluetooth LE connection setup procedures are documented by and Bluetooth LE connection setup procedures are documented by
skipping to change at page 7, line 9 skipping to change at page 7, line 15
6LBR. The 6LBR MUST ignore 6LNs with the same device address 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 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 Bluetooth LE device address at any given moment. This will avoid
addressing conflicts within a Bluetooth LE network. The IPSP depends addressing conflicts within a Bluetooth LE network. The IPSP depends
on Bluetooth version 4.1, and hence both Bluetooth version 4.1, or on Bluetooth version 4.1, and hence both Bluetooth version 4.1, or
newer, and IPSP version 1.0, or newer, are required for IPv6 newer, and IPSP version 1.0, or newer, are required for IPv6
communications. communications.
3.1. Protocol stack 3.1. Protocol stack
Figure 3 illustrates IPv6 over Bluetooth LE stack including the Figure 3 illustrates how IPv6 stack works in parallel to GATT stack
Internet Protocol Support Service. UDP and TCP are provided as on top of Bluetooth LE L2CAP layer. GATT stack is needed herein for
examples of transport protocols, but the stack can be used by any discovering nodes supporting Internet Protocol Support Service. UDP
other upper layer protocol capable of running atop of IPv6. The and TCP are provided as examples of transport protocols, but the
6LoWPAN layer runs on top of Bluetooth LE L2CAP layer. stack can be used by any other upper layer protocol capable of
running atop of IPv6.
+---------+ +----------------------------+ +---------+ +----------------------------+
| IPSS | | UDP/TCP/other | | IPSS | | UDP/TCP/other |
+---------+ +----------------------------+ +---------+ +----------------------------+
| GATT | | IPv6 | | GATT | | IPv6 |
+---------+ +----------------------------+ +---------+ +----------------------------+
| ATT | | 6LoWPAN for Bluetooth LE | | ATT | | 6LoWPAN for Bluetooth LE |
+---------+--+----------------------------+ +---------+--+----------------------------+
| Bluetooth LE L2CAP | | Bluetooth LE L2CAP |
- - +-----------------------------------------+- - - HCI - - +-----------------------------------------+- - - HCI
| Bluetooth LE Link Layer | | Bluetooth LE Link Layer |
+-----------------------------------------+ +-----------------------------------------+
| Bluetooth LE Physical | | Bluetooth LE Physical |
+-----------------------------------------+ +-----------------------------------------+
Figure 3: IPv6 over Bluetooth LE Stack Figure 3: IPv6 and IPSS on Bluetooth LE Stack
3.2. Link model 3.2. Link model
The concept of IPv6 link (layer 3) and the physical link (combination The concept of IPv6 link (layer 3) and the physical link (combination
of PHY and MAC) needs to be clear and the relationship has to be well of PHY and MAC) needs to be clear and the relationship has to be well
understood in order to specify the addressing scheme for transmitting understood in order to specify the addressing scheme for transmitting
IPv6 packets over the Bluetooth LE link. RFC 4861 [RFC4861] defines IPv6 packets over the Bluetooth LE link. RFC 4861 [RFC4861] defines
a link as "a communication facility or medium over which nodes can a link as "a communication facility or medium over which nodes can
communicate at the link layer, i.e., the layer immediately below communicate at the link layer, i.e., the layer immediately below
IPv6." IPv6."
skipping to change at page 8, line 9 skipping to change at page 8, line 13
6LoWPAN can function [IPSP], including handling the link-layer 6LoWPAN can function [IPSP], including handling the link-layer
fragmentation required on Bluetooth LE, as described in Section 2.4. fragmentation required on Bluetooth LE, as described in Section 2.4.
Even though MTUs larger than 1280 bytes can be supported, use of 1280 Even though MTUs larger than 1280 bytes can be supported, use of 1280
byte is RECOMMENDED in order to avoid need for Path MTU discovery byte is RECOMMENDED in order to avoid need for Path MTU discovery
procedures. procedures.
While Bluetooth LE protocols, such as L2CAP, utilize little-endian While Bluetooth LE protocols, such as L2CAP, utilize little-endian
byte orderering, IPv6 packets MUST be transmitted in big endian order byte orderering, IPv6 packets MUST be transmitted in big endian order
(network byte order). (network byte order).
This specification requires IPv6 header compression format specified Per this specification, the IPv6 header compression format specified
in RFC 6282 to be used [RFC6282]. It is assumed that the IPv6 in RFC 6282 MUST be used [RFC6282]. The IPv6 payload length can be
payload length can be inferred from the L2CAP header length and the derived from the L2CAP header length and the possibly elided IPv6
possibly elided IPv6 address can be inferred from the link-layer address can be reconstructed from the link-layer address, used at the
address, at the time of Bluetooth LE connection establishment, from time of Bluetooth LE connection establishment, from the HCI
the HCI Connection Handle during connection, and from context if any. Connection Handle during connection, compression context if any, and
from address registration information (see Section 3.2.2).
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. For Bluetooth LE multilink model has been IPv6 over Bluetooth LE (except for discovery of nodes supporting
chosen. Because of this, link-local multicast communications can IPSS). As the IPv6 over Bluetooth LE is intended for constrained
happen only within a single Bluetooth LE connection, and thus 6LN-to- nodes, and for Internet of Things use cases and environments,
6LN communications using link-local addresses are not possible. 6LNs multilink model's benefits are considered to overweight multilink
model's drawbacks described in RFC 4903 [RFC4903]. Hence a multilink
model has been chosen, as further illustrated in Section 3.3.
Because of this, link-local multicast communications can happen only
within a single Bluetooth LE connection, and thus 6LN-to-6LN
communications using link-local addresses are not possible. 6LNs
connected to the same 6LBR has to communicate with each other by connected to the same 6LBR has 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.2). collisions do not occur (see Section 3.2.2) and forwards packets sent
by one 6LN to another.
After the peripheral and central have connected at the Bluetooth LE After the peripheral and central have connected at the Bluetooth LE
level, the link can be considered up and IPv6 address configuration level, the link can be considered up and IPv6 address configuration
and transmission can begin. and transmission can begin.
3.2.1. Stateless address autoconfiguration 3.2.1. Stateless address autoconfiguration
At network interface initialization, both 6LN and 6LBR SHALL generate At network interface initialization, both 6LN and 6LBR SHALL generate
and assign to the 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
skipping to change at page 13, line 41 skipping to change at page 13, line 49
fully elide an address. fully elide an address.
3.2.4. Unicast and Multicast address mapping 3.2.4. 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 master is battery- efficient and particular care must be taken if the central is
powered. In the opposite direction, a 6LN always has to send packets battery-powered. In the opposite direction, a 6LN always has to send
to or through 6LBR. Hence, when a 6LN needs to transmit an IPv6 packets to or through 6LBR. Hence, when a 6LN needs to transmit an
multicast packet, the 6LN will unicast the corresponding Bluetooth LE IPv6 multicast packet, the 6LN will unicast the corresponding
packet to the 6LBR. Bluetooth LE packet to the 6LBR.
3.3. Subnets and Internet connectivity scenarios 3.3. Subnets and Internet connectivity scenarios
In a typical scenario, the Bluetooth LE network is connected to the In a typical scenario, the Bluetooth LE network is connected to the
Internet as shown in the Figure 6. In this scenario, the Bluetooth 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 LE star is deployed as one subnet, using one /64 IPv6 prefix, with
each spoke representing individual link. The 6LBR is acting as each spoke representing individual link. The 6LBR is acting as
router and forwarding packets between 6LNs and to and from Internet. router and forwarding packets between 6LNs and to and from Internet.
/ /
skipping to change at page 16, line 16 skipping to change at page 16, line 36
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
[BTCorev4.1] [BTCorev4.1]
Bluetooth Special Interest Group, "Bluetooth Core Bluetooth Special Interest Group, "Bluetooth Core
Specification Version 4.1", December 2013. Specification Version 4.1", December 2013,
<https://www.bluetooth.org/en-us/specification/adopted-
specifications>.
[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. December 2014, <https://www.bluetooth.org/en-
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, February 2006.
[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. September 2007.
skipping to change at page 17, line 33 skipping to change at page 18, line 5
[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. December 2003.
[RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)", [RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)",
RFC 3972, March 2005. RFC 3972, March 2005.
[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, October 2005.
[RFC4903] Thaler, D., "Multi-Link Subnet Issues", RFC 4903, June
2007.
[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, September 2007.
[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, September 2007.
[RFC5535] Bagnulo, M., "Hash-Based Addresses (HBA)", RFC 5535, June [RFC5535] Bagnulo, M., "Hash-Based Addresses (HBA)", RFC 5535, June
2009. 2009.
 End of changes. 24 change blocks. 
51 lines changed or deleted 77 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/