draft-ietf-6lo-btle-00.txt   draft-ietf-6lo-btle-01.txt 
6Lo Working Group J. Nieminen, Ed. 6Lo Working Group J. Nieminen
Internet-Draft T. Savolainen, Ed. Internet-Draft T. Savolainen
Intended status: Standards Track M. Isomaki Intended status: Standards Track M. Isomaki
Expires: May 11, 2014 Nokia Expires: November 3, 2014 Nokia
B. Patil B. Patil
AT&T AT&T
Z. Shelby Z. Shelby
Sensinode Arm
C. Gomez C. Gomez
Universitat Politecnica de Universitat Politecnica de Catalunya/i2CAT
Catalunya/i2CAT May 2, 2014
November 7, 2013
Transmission of IPv6 Packets over BLUETOOTH Low Energy Transmission of IPv6 Packets over BLUETOOTH(R) Low Energy
draft-ietf-6lo-btle-00 draft-ietf-6lo-btle-01
Abstract Abstract
BLUETOOTH Low Energy is a low power air interface technology defined Bluetooth Smart is the brand name for the low energy feature in the
by the BLUETOOTH Special Interest Group (BT-SIG). The standard Bluetooth specification defined by the Bluetooth Special Interest
BLUETOOTH radio has been widely implemented and available in mobile Group. The standard Bluetooth radio has been widely implemented and
phones, notebook computers, audio headsets and many other devices. available in mobile phones, notebook computers, audio headsets and
The low power version of BLUETOOTH is a new specification that many other devices. The low power version of Bluetooth is a
enables the use of this air interface with devices such as sensors, specification that enables the use of this air interface with devices
smart meters, appliances, etc. The low power variant of BLUETOOTH is such as sensors, smart meters, appliances, etc. The low power
currently specified in the revision 4.0 of the BLUETOOTH variant of Bluetooth is standardized since the revision 4.0 of the
specifications (BLUETOOTH 4.0). This document describes how IPv6 is Bluetooth specifications, although version 4.1 or newer is required
transported over BLUETOOTH Low Energy using 6LoWPAN techniques. for IPv6. This document describes how IPv6 is transported over
Bluetooth Low Energy using 6LoWPAN techniques.
Status of this Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
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 May 11, 2014. This Internet-Draft will expire on November 3, 2014.
Copyright Notice Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the
Copyright (c) 2014 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 Low Energy stack . . . . . . . . . . . . . . . . 4 2.1. Bluetooth Low Energy stack . . . . . . . . . . . . . . . 4
2.2. Link layer roles and topology . . . . . . . . . . . . . . 4 2.2. Link layer roles and topology . . . . . . . . . . . . . . 4
2.3. BT-LE device addressing . . . . . . . . . . . . . . . . . 5 2.3. Bluetooth LE device addressing . . . . . . . . . . . . . 5
2.4. BT-LE packets sizes and MTU . . . . . . . . . . . . . . . 5 2.4. Bluetooth LE packets sizes and MTU . . . . . . . . . . . 5
3. Specification of IPv6 over BLUETOOTH Low Energy . . . . . . . 6 3. Specification of IPv6 over Bluetooth Low Energy . . . . . . . 6
3.1. Protocol stack . . . . . . . . . . . . . . . . . . . . . . 6 3.1. Protocol stack . . . . . . . . . . . . . . . . . . . . . 6
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 . . . . . . . . . . . . . . . . . . 9 3.2.2. Neighbor discovery . . . . . . . . . . . . . . . . . 8
3.2.3. Header compression . . . . . . . . . . . . . . . . . . 9 3.2.3. Header compression . . . . . . . . . . . . . . . . . 9
3.2.4. Unicast and Multicast address mapping . . . . . . . . 10 3.2.3.1. Remote destination example . . . . . . . . . . . 10
3.3. Internet connectivity scenarios . . . . . . . . . . . . . 11 3.2.4. Unicast and Multicast address mapping . . . . . . . . 11
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 3.3. Internet connectivity scenarios . . . . . . . . . . . . . 11
5. Security Considerations . . . . . . . . . . . . . . . . . . . 12 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
6. Additional contributors . . . . . . . . . . . . . . . . . . . 12 5. Security Considerations . . . . . . . . . . . . . . . . . . . 12
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12 6. Additional contributors . . . . . . . . . . . . . . . . . . . 13
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13
8.1. Normative References . . . . . . . . . . . . . . . . . . . 13 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 13
8.2. Informative References . . . . . . . . . . . . . . . . . . 13 8.1. Normative References . . . . . . . . . . . . . . . . . . 13
Appendix A. BLUETOOTH Low Energy fragmentation and L2CAP Modes . 14 8.2. Informative References . . . . . . . . . . . . . . . . . 14
Appendix B. BLUETOOTH Low Energy L2CAP Channel ID Usage for Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14
6LoWPAN/IPv6 . . . . . . . . . . . . . . . . . . . . 14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15
1. Introduction 1. Introduction
BLUETOOTH Low Energy (BT-LE) is a radio technology targeted for Bluetooth low energy (LE) is a radio technology targeted for devices
devices that operate with coin cell batteries or minimalistic power that operate with coin cell batteries or minimalistic power sources,
sources, which means that low power consumption is essential. BT-LE which means that low power consumption is essential. Bluetooth LE is
is an especially attractive technology for Internet of Things an especially attractive technology for Internet of Things
applications, such as health monitors, environmental sensing, applications, such as health monitors, environmental sensing,
proximity applications and many others. proximity 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 and things, IPv6 is an ideal sensors and Internet connected devices and things, IPv6 is an ideal
protocol due to the large address space it provides. In addition, protocol due to the large address space it provides. In addition,
IPv6 provides tools for stateless address autoconfiguration, which is IPv6 provides tools for stateless address autoconfiguration, which is
particularly suitable for sensor network applications and nodes which particularly suitable for sensor network applications and nodes which
have very limited processing power or lack a full-fledged operating have very limited processing power or lack a full-fledged operating
system. system.
RFC 4944 [RFC4944] specifies the transmission of IPv6 over IEEE RFC 4944 [RFC4944] specifies the transmission of IPv6 over IEEE
802.15.4. The BT-LE link in many respects has similar 802.15.4. The Bluetooth LE link in many respects has similar
characteristics to that of IEEE 802.15.4. Many of the mechanisms characteristics to that of IEEE 802.15.4. Many of the mechanisms
defined in the RFC 4944 can be applied to the transmission of IPv6 on defined in the RFC 4944 can be applied to the transmission of IPv6 on
BT-LE links. This document specifies the details of IPv6 Bluetooth LE links. This document specifies the details of IPv6
transmission over BT-LE links. 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 BT-LE master and BT-LE slave can both be either 6LN or addition that Bluetooth LE central and Bluetooth LE peripheral can
6LBR. both be either 6LN or 6LBR.
2. BLUETOOTH Low Energy 2. Bluetooth Low Energy
BT-LE is designed for transferring small amounts of data infrequently Bluetooth LE is designed for transferring small amounts of data
at modest data rates at a very low cost per bit. BLUETOOTH Special infrequently at modest data rates at a very low cost per bit.
Interest Group has introduced two trademarks, BLUETOOTH Smart for Bluetooth Special Interest Group (Bluetooth SIG) has introduced two
single-mode devices (a device that only supports BT-LE) and BLUETOOTH trademarks, Bluetooth Smart for single-mode devices (a device that
Smart Ready for dual-mode devices. In the rest of the draft, the only supports Bluetooth LE) and Bluetooth Smart Ready for dual-mode
term BT-LE refers to both types of devices. devices. In the rest of the document, the term Bluetooth LE refers
to both types of devices.
Bluetooth LE was introduced in Bluetooth 4.0 and further enhanced in
Bluetooth 4.1 [BTCorev4.1]. Bluetooth SIG will also publish Internet
Protocol Support Profile (IPSP) [IPSP], which includes Internet
Protocol Support Service (IPSS) and that enables discovery of IP-
enabled devices and establishment of link-layer connection for
transporting IPv6 packets. IPv6 over Bluetooth LE is dependent on
both Bluetooth 4.1 and IPSP.
BT-LE is an integral part of the BT 4.0 specification [BTCorev4.0].
Devices such as mobile phones, notebooks, tablets and other handheld Devices such as mobile phones, notebooks, tablets and other handheld
computing devices which include BT 4.0 chipsets also have the low- computing devices which will include Bluetooth 4.1 chipsets will also
energy functionality of BLUETOOTH. BT-LE is also included in many have the low-energy functionality of Bluetooth. Bluetooth LE will
different types of accessories that collaborate with mobile devices also be included in many different types of accessories that
such as phones, tablets and notebook computers. An example of a use collaborate with mobile devices such as phones, tablets and notebook
case for a BT-LE accessory is a heart rate monitor that sends data computers. An example of a use case for a Bluetooth LE accessory is
via the mobile phone to a server on the Internet. a heart rate monitor that sends data via the mobile phone to a server
on the Internet.
2.1. BLUETOOTH Low Energy stack 2.1. Bluetooth Low Energy stack
The lower layer of the BT-LE stack consists of the Physical (PHY) and The lower layer of the Bluetooth LE stack consists of the Physical
the Link Layer (LL). The Physical Layer transmits and receives the (PHY) and the Link Layer (LL). The Physical Layer transmits and
actual packets. The Link Layer is responsible for providing medium receives the actual packets. The Link Layer is responsible for
access, connection establishment, error control and flow control. providing medium access, connection establishment, error control and
The upper layer consists of the Logical Link Control and Adaptation flow control. The upper layer consists of the Logical Link Control
Protocol (L2CAP), Generic Attribute protocol (GATT) and Generic and Adaptation Protocol (L2CAP), Attribute Protocol (ATT), Generic
Access Profile (GAP) as shown in Figure 1. GATT and BT-LE profiles Attribute Profile (GATT) and Generic Access Profile (GAP) as shown in
together enable the creation of applications in a standardized way Figure 1. The device internal Host Controller Interface (HCI)
without using IP. L2CAP provides multiplexing capability by separates the lower layers, often implemented in the Bluetooth
multiplexing the data channels from the above layers. L2CAP also controller, from higher layers, often implemented in the host stack.
provides fragmentation and reassembly for large data packets. 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.
+----------------------------------------+------------------+ +-------------------------------------------------+
| Applications | | Applications |
+----------------------------------------+------------------+ +---------------------------------------+---------+
| Generic Attribute Profile | Generic Access | | Generic Attribute Profile | Generic |
+----------------------------------------+ Profile | +--------------------+------------------+ Access |
| Attribute Protocol |Security Manager | | | Attribute Protocol | Security Manager | Profile |
+--------------------+-------------------+------------------+ +--------------------+------------------+---------+
| Logical Link Control and Adaptation | | Logical Link Control and Adaptation Protocol |
+--------------------+-------------------+------------------+ - - -+-----------------------+-------------------------+- - - HCI
| Host Controller Interface | | Link Layer | Direct Test Mode |
+--------------------+-------------------+------------------+ +-------------------------------------------------+
| Link Layer | Direct Test Mode | | Physical Layer |
+--------------------+-------------------+------------------+ +-------------------------------------------------+
| Physical Layer |
+--------------------+-------------------+------------------+
Figure 1: BT-LE Protocol Stack Figure 1: Bluetooth LE Protocol Stack
2.2. Link layer roles and topology 2.2. Link layer roles and topology
BT-LE defines two Link Layer roles: the BT-LE master role and the Bluetooth LE defines two Link Layer roles: the Bluetooth LE central
BT-LE slave role. A device in the master role, which is called role and the Bluetooth LE peripheral role. A device in the central
master from now on, can manage multiple simultaneous connections with role, which is called central from now on, has traditionally been
a number of devices in the slave role, called slaves from now on. A able to manage multiple simultaneous connections with a number of
slave can only be connected to a single master. Hence, a BT-LE devices in the peripheral role, called peripherals from now on. A
network (i.e. a BT-LE piconet) follows a star topology shown in the peripheral is commonly connected to a single central, but since
Figure 2. This specification primarily addresses the situation where Bluetooth 4.1 can also connect to multiple centrals. In this
the slave is a 6LN but not a 6LBR at the IPv6 level. document for IPv6 networking purposes the Bluetooth LE network (i.e.
a Bluetooth LE piconet) follows a star topology shown in the
[BT-LE slave]-----\ /-----[BT-LE slave] Figure 2, where the router typically implements the Bluetooth LE
\ / central role and nodes Bluetooth LE peripheral roles. In the future
[BT-LE slave]-----+[BT-LE Master]+-----[BT-LE slave] mesh networking may be defined for IPv6 over Bluetooth LE.
/ \
[BT-LE slave]-----/ \-----[BT-LE slave]
Figure 2: BT-LE Star Topology Node --. .-- Node
\ /
Node ---- Router ---- Node
/ \
Node --' '-- Node
A master is assumed to be less constrained than a slave. Hence, in Figure 2: Bluetooth LE Star Topology
the primary scenario master and slave will act as 6LoWPAN Border
Router (6LBR) and a 6LoWPAN Node (6LN), respectively.
In BT-LE, communication only takes place between a master and a In Bluetooth LE a central is assumed to be less constrained than a
slave. Hence, in a BT-LE network using IPv6, a radio hop is peripheral. Hence, in the primary deployment scenario central and
equivalent to an IPv6 link and vice versa. peripheral will act as 6LoWPAN Border Router (6LBR) and a 6LoWPAN
Node (6LN), respectively.
2.3. BT-LE device addressing In Bluetooth LE, direct communication only takes place between a
central and a peripheral. Hence, in a Bluetooth LE network using
IPv6, a radio hop is equivalent to an IPv6 link and vice versa.
Every BT-LE device is identified by a 48-bit device address. The 2.3. Bluetooth LE device addressing
BLUETOOTH specification describes the device address of a BTLE device
as:"Devices are identified using a device address. Device addresses
may be either a public device address or a random device address."
[BTCorev4.0]. The public device addresses are based on the IEEE 802-
2001 standard [IEEE802-2001]. The random device addresses are
generated as defined in the BLUETOOTH specification. The device
addresses are always unique within a BT-LE piconet, but the random
addresses are not guaranteed to be globally unique.
2.4. BT-LE packets sizes and MTU Every Bluetooth LE device is identified by a 48-bit device address.
The Bluetooth specification describes the device address of a
Bluetooth LE device as:"Devices are identified using a device
address. Device addresses may be either a public device address or a
random device address." [BTCorev4.1]. The public device addresses
are based on the IEEE 802-2001 standard [IEEE802-2001]. The random
device addresses are generated as defined in the Bluetooth
specification. The device addresses are always unique within a
Bluetooth LE piconet, but the random addresses are not guaranteed to
be globally unique.
Maximum size of the payload in the BT-LE data channel PDU is 27 2.4. Bluetooth LE packets sizes and MTU
bytes. Depending on the L2CAP mode in use, the amount of data
available for transporting bytes in the single BT-LE data channel PDU
ranges between 19 and 27 octets. For power efficient communication
between two BT-LE nodes, data and its header should fit in a single
BT-LE data channel PDU. However, IPv6 requires support for an MTU of
1280 bytes. An inherent function of the BT-LE L2CAP layer, called
Fragmentation and Recombination (FAR), can assist in transferring
IPv6 packets that do not fit in a single BT-LE data channel PDU.
The maximum IPv6 datagram size that can be transported by L2CAP Optimal MTU defined for L2CAP fixed channels over Bluetooth LE is 27
depends on the L2CAP mode. The Basic L2CAP Mode allows a maximum bytes including the L2CAP header of four bytes. Default MTU for
payload size (i.e. IPv6 datagram size) of 65535 bytes per L2CAP PDU. Bluetooth LE is hence defined to be 27 bytes. Therefore, excluding
L2CAP header of four bytes, protocol data unit (PDU) size of 23 bytes
is available for upper layers. In order to be able to transmit IPv6
packets of 1280 bytes or larger, 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 MTU of
1280 bytes or higher for the IPv6 layer [IPSP].
The rest of the L2CAP modes allow a maximum payload size that ranges 3. Specification of IPv6 over Bluetooth Low Energy
between 65527 and 65533 bytes per L2CAP PDU. Appendix A describes
FAR operation and five L2CAP Modes.
3. Specification of IPv6 over BLUETOOTH Low Energy Before any IP-layer communications can take place over Bluetooth LE,
Bluetooth LE enabled nodes 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
Bluetooth SIG in the IPSP specification [IPSP], and hence are out of
scope of this document. The IPSP depends on Bluetooth version 4.1,
and hence both Bluetooth version 4.1 or newer and IPSP are required
for IPv6 communications.
BT-LE technology sets strict requirements for low power consumption Bluetooth LE technology sets strict requirements for low power
and thus limits the allowed protocol overhead. 6LoWPAN standards consumption and thus limits the allowed protocol overhead. 6LoWPAN
[RFC4944], [RFC6775], and [RFC6282] provide useful functionality for standards [RFC6775], and [RFC6282] provide useful functionality for
reducing overhead which can be applied to BT-LE. This functionality reducing overhead which can be applied to Bluetooth LE. This
comprises of link-local IPv6 addresses and stateless IPv6 address functionality comprises of link-local IPv6 addresses and stateless
autoconfiguration (see Section 3.2.1), Neighbor Discovery (see IPv6 address autoconfiguration (see Section 3.2.1), Neighbor
Section 3.2.2) and header compression (see Section 3.2.3). Discovery (see Section 3.2.2) and header compression (see
Section 3.2.3).
A significant difference between IEEE 802.15.4 and BT-LE is that the A significant difference between IEEE 802.15.4 and Bluetooth LE is
former supports both star and mesh topology (and requires a routing that the former supports both star and mesh topology (and requires a
protocol), whereas BT-LE does not currently support the formation of routing protocol), whereas Bluetooth LE does not currently support
multihop networks at the link layer. In consequence, the mesh header the formation of multihop networks at the link layer.
defined in [RFC4944] for mesh under routing MUST NOT be used in BT-LE
networks. In addition, a BT-LE node MUST NOT play the role of a
6LoWPAN Router (6LR).
3.1. Protocol stack 3.1. Protocol stack
In order to enable transmission of IPv6 packets over BT-LE, a new Figure 3 illustrates IPv6 over Bluetooth LE stack including the
fixed L2CAP Channel Identifier (Channel ID) is to be reserved for Internet Protocol Support Service. UDP and TCP are provided as
IPv6 traffic by the BT-SIG. Until the Channel ID is reserved, examples of transport protocols, but the stack can be used by any
prototype implementations can be implemented as is described in the other upper layer protocol capable of running atop of IPv6. The
Appendix B. 6LoWPAN runs on top of Bluetooth LE L2CAP layer.
Figure 3 illustrates IPv6 over BT-LE stack. 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.
+----------------------------+ +---------+ +----------------------------+
| UDP/TCP/other | | IPSS | | UDP/TCP/other |
+----------------------------+ +---------+ +----------------------------+
| IPv6 | | GATT | | IPv6 |
+----------------------------+ +---------+ +----------------------------+
| 6LoWPAN adapted to BT-LE | | ATT | | 6LoWPAN adapted to LE |
+----------------------------+ +---------+--+----------------------------+
| BT-LE L2CAP | | Bluetooth LE L2CAP |
+----------------------------+ - - +-----------------------------------------+- - - HCI
| BT-LE Link Layer | | Bluetooth LE Link Layer |
+----------------------------+ +-----------------------------------------+
| BT-LE Physical | | Bluetooth LE Physical |
+----------------------------+ +-----------------------------------------+
Figure 3: IPv6 over BT-LE Stack Figure 3: IPv6 over 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 BT-LE link. RFC 4861 [RFC4861] defines a link IPv6 packets over the Bluetooth LE link. RFC 4861 [RFC4861] defines
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."
In the case of BT-LE, L2CAP is an adaptation layer that supports the In the case of Bluetooth LE, 6LoWPAN layer is adapted to support
transmission of IPv6 packets. L2CAP also provides multiplexing transmission of IPv6 packets over Bluetooth LE. The IPSP defines all
capability in addition to FAR functionality. This specification steps required for setting up the Bluetooth LE connection over which
requires that FAR functionality MUST be provided in the L2CAP layer. 6LoWPAN can function [IPSP], including handling the link-layer
The L2CAP channel characteristics for the transmission of IPv6 fragmentation required on Bluetooth LE, as described in Section 2.4.
packets on top of BT-LE are the following:
MTU: Equal to or greater than 1280 bytes
Flush Timeout: 0xFFFF (Infinite)
QoS: Best Effort
Mode: Basic Mode
Since FAR in BT-LE is a function of the L2CAP layer, fragmentation This specification also assumes the IPv6 header compression format
functionality as defined in RFC 4944 [RFC4944] MUST NOT be used in specified in RFC 6282 is used [RFC6282]. It is also assumed that the
BT-LE networks. This specification also assumes the IPv6 header IPv6 payload length can be inferred from the L2CAP header length and
compression format specified in RFC 6282 [RFC6282]. It is also the IID value inferred from the link-layer address with help of
assumed that the IPv6 payload length can be inferred from the L2CAP Neighbor Cache, if elided from compressed packet.
header length and the IID value inferred, with help of Neighbor
Cache, from the link-layer address.
The BT-LE link between two communicating nodes can be considered to The Bluetooth LE link between two communicating nodes can be
be a point-to-point or point-to-multipoint link. When one of the considered to be a point-to-point or point-to-multipoint link. When
communicating nodes is in the role of a master, then the link can be one of the communicating nodes is simultaneously connected to
viewed as a point-to-multipoint link from the master point of view. multiple nodes, the link can be viewed as a point-to-multipoint link
However, due to BT-LE star topology, each branch of the star is from the particular node point of view. However, due to Bluetooth LE
considered to be an individual link and thus the slaves cannot star topology, each branch of the star is considered to be an
directly hear each other and also cannot talk to each other with individual link and thus only two nodes can directly talk to each
link-local addresses. The master ensures address collisions do not other. Node-to-node communications, e.g. using link-local addresses,
occur (see Section 3.2.2). need to be bridged by the 6LBR. The 6LBR ensures address collisions
do not occur (see Section 3.2.2).
After the slave and master have connected at the BT-LE level, the After the peripheral and central have connected at the Bluetooth LE
link can be considered up and IPv6 address configuration and level, the link can be considered up and IPv6 address configuration
transmission can begin. and transmission can begin.
3.2.1. Stateless address autoconfiguration 3.2.1. Stateless address autoconfiguration
A BT-LE 6LN performs stateless address autoconfiguration as per RFC A Bluetooth LE 6LN performs stateless address autoconfiguration as
4862 [RFC4862]. A 64-bit Interface identifier (IID) for a BT-LE per RFC 4862 [RFC4862]. A 64-bit Interface identifier (IID) for a
interface MAY be formed by utilizing the 48-bit BLUETOOTH device Bluetooth LE interface MAY be formed by utilizing the 48-bit
address (see Section 2.3) as defined in RFC 2464 "IPv6 over Ethernet" Bluetooth device address (see Section 2.3) as defined in RFC 2464
specification [RFC2464]. Alternatively, a randomly generated IID "IPv6 over Ethernet" specification [RFC2464]. Alternatively, a
(see Section 3.2.2), MAY be used instead. In the case of randomly randomly generated IID (see Section 3.2.2) can be used instead, for
generated IID or randomly generated BLUETOOTH device address, the example, as discussed in [I-D.ietf-6man-default-iids]. In the case
"Universal/Local" bit MUST be set to 0 [RFC4291]. Only if the of randomly generated IID or randomly generated Bluetooth device
BLUETOOTH device address is known to be a public address the address, the "Universal/Local" bit MUST be set to 0 [RFC4291]. Only
if the Bluetooth device address is known to be a public address the
"Universal/Local" bit can be set to 1. "Universal/Local" bit can be set to 1.
As defined in RFC 4291 [RFC4291], the IPv6 link-local address for a As defined in RFC 4291 [RFC4291], the IPv6 link-local address for a
BT-LE node is formed by appending the IID, to the prefix FE80::/64, Bluetooth LE node is formed by appending the IID, to the prefix
as depicted in Figure 4. FE80::/64, as depicted in Figure 4.
10 bits 54 bits 64 bits 10 bits 54 bits 64 bits
+----------+-----------------+----------------------+ +----------+-----------------+----------------------+
|1111111010| zeros | Interface Identifier | |1111111010| zeros | Interface Identifier |
+----------+-----------------+----------------------+ +----------+-----------------+----------------------+
Figure 4: IPv6 link-local address in BT-LE Figure 4: IPv6 link-local address in Bluetooth LE
The tool for a 6LBR to obtain an IPv6 prefix for numbering the BT-LE The tool for a 6LBR to obtain an IPv6 prefix for numbering the
network is out of scope of this document, but can be, for example, Bluetooth LE network is out of scope of this document, but can be,
accomplished via DHCPv6 Prefix Delegation [RFC3633] or by using for example, accomplished via DHCPv6 Prefix Delegation [RFC3633] or
Unique Local IPv6 Unicast Addresses (ULA) [RFC4193]. Due to the link by using Unique Local IPv6 Unicast Addresses (ULA) [RFC4193]. Due to
model of the BT-LE (see Section 2.2) the 6LBR MUST set the "on-link" the link model of the Bluetooth LE (see Section 2.2) the 6LBR MUST
flag (L) to zero in the Prefix Information Option [RFC4861]. This set the "on-link" flag (L) to zero in the Prefix Information Option
will cause 6LNs to always send packets to the 6LBR, including the [RFC4861]. This will cause 6LNs to always send packets to the 6LBR,
case when the destination is another 6LN using the same prefix. including the case when the destination is another 6LN using the same
prefix.
3.2.2. Neighbor discovery 3.2.2. 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. BT-LE does not support mesh networks including the mesh topology. Bluetooth LE does not support mesh
and hence only those aspects that apply to a star topology are networks and hence only those aspects that apply to a star topology
considered. are considered.
The following aspects of the Neighbor Discovery optimizations The following aspects of the Neighbor Discovery optimizations
[RFC6775] are applicable to BT-LE 6LNs: [RFC6775] are applicable to Bluetooth LE 6LNs:
1. A BT-LE 6LN MUST register its address with the 6LBR by sending a 1. A Bluetooth LE 6LN MUST register its addresses with the 6LBR by
Neighbor Solicitation (NS) message with the ARO option and process sending a Neighbor Solicitation (NS) message with the Address
the Neighbor Advertisement (NA) accordingly. The NS with the ARO Registration Option (ARO) and process the Neighbor Advertisement (NA)
option SHOULD be sent irrespective of whether the IID is derived from accordingly. The NS with the ARO option SHOULD be sent irrespective
the unique 48 bit BT-LE device address or the IID is a random value of the method used to generate the IID. The 6LN MUST register only
that is generated as per the privacy extensions for stateless address one IPv6 address per IPv6 prefix available on a link.
autoconfiguration [RFC4941]. Although RFC 4941 [RFC4941] permits the
use of deprecated addresses for old connections, in this
specification we mandate that one interface MUST NOT use more than
one IID at any one time.
2. For sending Router Solicitations and processing Router 2. For sending Router Solicitations and processing Router
Advertisements the BT-LE 6LNs MUST, respectively, follow Sections 5.3 Advertisements the Bluetooth LE 6LNs MUST, respectively, follow
and 5.4 of the [RFC6775]. Sections 5.3 and 5.4 of the [RFC6775].
3.2.3. Header compression 3.2.3. 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 in this document as the basis for IPv6 header compression on
top of BT-LE. All headers MUST be compressed according to RFC 6282 top of Bluetooth LE. All headers MUST be compressed according to RFC
[RFC6282] encoding formats. The BT-LE's star topology structure can 6282 [RFC6282] encoding formats.
be exploited in order to provide a mechanism for IID compression.
The following text describes the principles of IPv6 address
compression on top of BT-LE.
In a link-local communication, both the IPv6 source and destination The Bluetooth LE's star topology structure and ARO can be exploited
addresses MUST be elided [RFC6282], since the node knows that the in order to provide a mechanism for IID compression. The following
packet is destined for it even if the packet does not have text describes the principles of IPv6 address compression on top of
destination IPv6 address. On the other hand, a node SHALL learn the Bluetooth LE.
IID of the other endpoint of each L2CAP connection it participates
in. By exploiting this information, a node that receives a data The ARO option requires use of EUI-64 identifier [RFC6775]. In the
channel PDU containing an IPv6 packet (or a part of it) can infer the case of Bluetooth LE, the field SHALL be filled with the 48-bit
corresponding IPv6 source address. A node MUST maintain a Neighbor device address used by the Bluetooth LE node converted into 64-bit
Cache, in which the entries include both the IID of the neighbor and Modified EUI-64 format [RFC4291].
the Device Address that identifies the neighbor. For the type of
communication considered in this paragraph, the following settings When a 6LN is sending a packet to or through a 6LBR, it MUST fully
MUST be used in the IPv6 compressed header: CID=0, SAC=0, SAM=11, elide the source address if the source IPv6 address is currently
DAC=0, DAM=11. registed with ARO to the 6LBR and the 6LN has registered only one
address for the indicated prefix. That is, if SAC=0 and SAM=11 the
6LN MUST have registered the source link-local IPv6 address it is
using using ARO, and if SAC=1 and SAM=11 the 6LN MUST have registered
the source IPv6 address with the prefix related to compression
context identified with Context Identifier Extension. The
destination IPv6 address MUST be fully elided if the destination
address is the same address to which the 6LN has succesfully
registered its source IPv6 address with ARO (set DAC=0, DAM=11). The
destination IPv6 address MUST be fully or partially elided if the
destination address has prefix for which context has been set up, for
example, DAC=0 and DAM=01 when destination is link-local, and DAC=1
and DAM=01 with Context Identifier Extension if compression context
has been configured for the used destination.
When a 6LBR is transmitting packets to 6LN, it MUST fully elide the
source IID if the source IPv6 address is the one 6LN has used to
register its address with ARO (set 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 elide the
destination IPv6 address if it is currently registered by the 6LN
with ARO and thus 6LN can determine it based on indication of link-
local prefix (DAC=0) or indication of other prefix (DAC=1 with
Context Identifier Extension).
3.2.3.1. Remote destination example
When a 6LN transmits an IPv6 packet to a remote destination using When a 6LN transmits an IPv6 packet to a remote destination using
global Unicast IPv6 addresses, if a context is defined for the prefix global Unicast IPv6 addresses, if a context is defined for the prefix
of the 6LNs global IPv6 address, the 6LN MUST indicate this context of the 6LNs global IPv6 address, the 6LN has to indicate this context
in the corresponding source fields of the compressed IPv6 header as in the corresponding source fields of the compressed IPv6 header as
per Section 3.1 of RFC 6282 [RFC6282], and MUST elide the IPv6 source per Section 3.1 of RFC 6282 [RFC6282], and has to elide the IPv6
address. For this, the 6LN MUST use the following settings in the source address previously registered with ARO. For this, the 6LN
IPv6 compressed header: CID=1, SAC=1, SAM=11. In this case, the 6LBR MUST use the following settings in the IPv6 compressed header: CID=1,
can infer the elided IPv6 source address since 1) the 6LBR has SAC=1, SAM=11. In this case, the 6LBR can infer the elided IPv6
previously assigned the prefix to the 6LNs; and 2) the 6LBR maintains source address since 1) the 6LBR has previously assigned the prefix
a Neighbor Cache that relates the Device Address and the IID of the to the 6LNs; and 2) the 6LBR maintains a Neighbor Cache that relates
corresponding slave. If a context is defined for the IPv6 the Device Address and the IID the device has registered with ARO.
destination address, the 6LN MUST also indicate this context in the If a context is defined for the IPv6 destination address, the 6LN has
corresponding destination fields of the compressed IPv6 header, and to also indicate this context in the corresponding destination fields
MUST elide the prefix of the destination IPv6 address. For this, the of the compressed IPv6 header, and elide the prefix of the
6LN MUST set the DAM field of the compressed IPv6 header as DAM=01 destination IPv6 address. For this, the 6LN MUST set the DAM field
(if the context covers a 64-bit prefix) or as DAM=11 (if the context of the compressed IPv6 header as DAM=01 (if the context covers a
covers a full, 128-bit address). CID and DAC MUST be set to CID=1 64-bit prefix) or as DAM=11 (if the context covers a full, 128-bit
and DAC=1. Note that when a context is defined for the IPv6 address). CID and DAC MUST be set to CID=1 and DAC=1. Note that
destination address, the 6LBR can infer the elided destination prefix when a context is defined for the IPv6 destination address, the 6LBR
by using the context. can infer the elided destination prefix by using the context.
When a 6LBR receives an IPv6 packet sent by a remote node outside the When a 6LBR receives an IPv6 packet sent by a remote node outside the
BT-LE network, and the destination of the packet is a 6LN, if a Bluetooth LE network, and the destination of the packet is a 6LN, if
context is defined for the prefix of the 6LN's global IPv6 address, a context is defined for the prefix of the 6LN's global IPv6 address,
the 6LBR MUST indicate this context in the corresponding destination the 6LBR has to indicate this context in the corresponding
fields of the compressed IPv6 header, and MUST elide the IPv6 destination fields of the compressed IPv6 header. The 6LBR has to
destination address of the packet before forwarding it to the 6LN. elide the IPv6 destination address of the packet before forwarding
For this, the 6LBR MUST set the DAM field of the IPv6 compressed it, if the IPv6 destination address is inferable by the 6LN. For
header as DAM=11. CID and DAC MUST be set to CID=1 and DAC=1. If a this, the 6LBR will set the DAM field of the IPv6 compressed header
as DAM=11. CID and DAC needs to be set to CID=1 and DAC=1. If a
context is defined for the prefix of the IPv6 source address, the context is defined for the prefix of the IPv6 source address, the
6LBR MUST indicate this context in the source fields of the 6LBR needs to indicate this context in the source fields of the
compressed IPv6 header, and MUST elide that prefix as well. For compressed IPv6 header, and elide that prefix as well. For this, the
this, the 6LBR MUST set the SAM field of the IPv6 compressed header 6LBR needs to set the SAM field of the IPv6 compressed header as
as SAM=01 (if the context covers a 64-bit prefix) or SAM=11 (if the SAM=01 (if the context covers a 64-bit prefix) or SAM=11 (if the
context covers a full, 128-bit address). CID and SAC MUST be set to context covers a full, 128-bit address). CID and SAC are to be set
CID=1 and SAC=1. to CID=1 and SAC=1.
3.2.4. Unicast and Multicast address mapping 3.2.4. Unicast and Multicast address mapping
The BT-LE link layer does not support multicast. Hence traffic is The Bluetooth LE link layer does not support multicast. Hence
always unicast between two BT-LE nodes. Even in the case where a traffic is always unicast between two Bluetooth LE nodes. Even in
master is attached to multiple slaves, the master cannot do a the case where a 6LBR is attached to multiple 6LNs, the 6LBR cannot
multicast to all the connected slaves. If the master needs to send a do a multicast to all the connected 6LNs. If the 6LBR needs to send
multicast packet to all its slaves, 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 master is battery-
powered. In the opposite direction, a slave can only transmit data powered. In the opposite direction, a 6LN can only transmit data to
to a single destination (i.e. the master). Hence, when a slave needs a single destination (i.e. the 6LBR). Hence, when a 6LN needs to
to transmit an IPv6 multicast packet, the slave will unicast the transmit an IPv6 multicast packet, the 6LN will unicast the
corresponding BT-LE packet to the master. As described in the corresponding Bluetooth LE packet to the 6LBR. The 6LBR will then
Section 3.2 the master will not forward link-local multicast messages forward the multicast packet to other 6LNs. To avoid excess unwanted
to other slaves connected to the master. multicast traffic being sent to 6LNs, the 6LBR SHOULD implement MLD
Snooping feature [RFC4541].
3.3. Internet connectivity scenarios 3.3. Internet connectivity scenarios
In a typical scenario, the BT-LE network is connected to the Internet In a typical scenario, the Bluetooth LE network is connected to the
as shown in the Figure 5. Internet as shown in the Figure 5.
A degenerate scenario can be imagined where a slave is acting as 6LBR
and providing Internet connectivity for the master. How the master
could then further provide Internet connectivity to other slaves,
possibly connected to the master, is out of the scope of this
document.
6LN 6LN
\ ____________ \ ____________
\ / \ \ / \
6LN ---- 6LBR --- | Internet | 6LN ---- 6LBR ----- | Internet |
/ \____________/ / \____________/
/ /
6LN 6LN
<-- BT-LE --> <-- Bluetooth LE -->
Figure 5: BT-LE network connected to the Internet Figure 5: Bluetooth LE network connected to the Internet
In some scenarios, the BT-LE network may transiently or permanently In some scenarios, the Bluetooth LE network may transiently or
be an isolated network as shown in the Figure 6. permanently be an isolated network as shown in the Figure 6.
6LN 6LN 6LN 6LN
\ / \ /
\ / \ /
6LN --- 6LBR --- 6LN 6LN --- 6LBR --- 6LN
/ \ / \
/ \ / \
6LN 6LN 6LN 6LN
<------ BT-LE -----> <--- Bluetooth LE --->
Figure 6: Isolated BT-LE network
Figure 6: 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.
In the isolated network scenario communications between 6LN and 6LBR In the isolated network scenario communications between 6LN and 6LBR
can use IPv6 link-local methodology, but for communications between can use IPv6 link-local methodology, but for communications between
different slaves, the master has to act as 6LBR, number the network different 6LNs, the 6LBR has to number the network with ULA prefix
with ULA prefix [RFC4193], and route packets between slaves. [RFC4193], and route packets between 6LNs.
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 BT-LE links has similar requirements The transmission of IPv6 over Bluetooth LE links has similar
and concerns for security as for IEEE 802.15.4. IPv6 over BT-LE requirements and concerns for security as for IEEE 802.15.4.
SHOULD be protected by using BT-LE Link Layer security. Bluetooth LE Link Layer security considerations are covered by the
IPSP [IPSP].
BT-LE Link Layer supports encryption and authentication by using the Bluetooth LE Link Layer supports encryption and authentication by
Counter with CBC-MAC (CCM) mechanism [RFC3610] and a 128-bit AES using the Counter with CBC-MAC (CCM) mechanism [RFC3610] and a
block cipher. Upper layer security mechanisms may exploit this 128-bit AES block cipher. Upper layer security mechanisms may
functionality when it is available. (Note: CCM does not consume exploit this functionality when it is available. (Note: CCM does not
bytes from the maximum per-packet L2CAP data size, since the link consume bytes from the maximum per-packet L2CAP data size, since the
layer data unit has a specific field for them when they are used.) link layer data unit has a specific field for them when they are
used.)
Key management in BT-LE is provided by the Security Manager Protocol Key management in Bluetooth LE is provided by the Security Manager
(SMP), as defined in [BTCorev4.0]. Protocol (SMP), as defined in [BTCorev4.1].
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, Erik Nordmark, and Marcel De Kogel have provided Samita Chakrabarti, Erik Nordmark, and Marcel De Kogel have provided
valuable feedback for this draft. valuable feedback for this draft.
Authors would like to give special acknowledgements for Krishna
Shingala, Frank Berntsen, and Bluetooth SIG's Internet Working Group
for providing significant feedback and improvement proposals for this
document.
8. References 8. References
8.1. Normative References 8.1. Normative References
[BTCorev4.0] [BTCorev4.1]
BLUETOOTH Special Interest Group, "BLUETOOTH Specification Bluetooth Special Interest Group, "Bluetooth Core
Version 4.0", June 2010. Specification Version 4.1", December 2013.
[IPSP] Bluetooth Special Interest Group, "Bluetooth Internet
Protocol Support Profile Specification - REFERENCE TO BE
UPDATED ONCE IPSP IS PUBLISHED", 2014.
[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.
[RFC2464] Crawford, M., "Transmission of IPv6 Packets over Ethernet [RFC2464] Crawford, M., "Transmission of IPv6 Packets over Ethernet
Networks", RFC 2464, December 1998. Networks", RFC 2464, December 1998.
[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.
[RFC4541] Christensen, M., Kimball, K., and F. Solensky,
"Considerations for Internet Group Management Protocol
(IGMP) and Multicast Listener Discovery (MLD) Snooping
Switches", RFC 4541, May 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.
[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, September 2007.
[RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler,
"Transmission of IPv6 Packets over IEEE 802.15.4
Networks", RFC 4944, September 2007.
[RFC6282] Hui, J. and P. Thubert, "Compression Format for IPv6 [RFC6282] Hui, J. 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. September 2011.
[RFC6775] Shelby, Z., Chakrabarti, S., Nordmark, E., and C. Bormann, [RFC6775] Shelby, Z., Chakrabarti, S., Nordmark, E., and C. Bormann,
"Neighbor Discovery Optimization for IPv6 over Low-Power "Neighbor Discovery Optimization for IPv6 over Low-Power
Wireless Personal Area Networks (6LoWPANs)", RFC 6775, Wireless Personal Area Networks (6LoWPANs)", RFC 6775,
November 2012. November 2012.
8.2. Informative References 8.2. Informative References
[I-D.ietf-6man-default-iids]
Gont, F., Cooper, A., Thaler, D., and W. Will,
"Recommendation on Stable IPv6 Interface Identifiers",
draft-ietf-6man-default-iids-00 (work in progress),
January 2014.
[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.
[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, September 2003.
[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.
[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.
[RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy [RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler,
Extensions for Stateless Address Autoconfiguration in "Transmission of IPv6 Packets over IEEE 802.15.4
IPv6", RFC 4941, September 2007. Networks", RFC 4944, September 2007.
Appendix A. BLUETOOTH Low Energy fragmentation and L2CAP Modes
This section provides an overview of Fragmentation and Recombination
(FAR) method and L2CAP modes in BT-LE. FAR is an L2CAP mechanism, in
which an L2CAP entity can take the (large) upper layer PDU, prepend
the L2CAP header (4 bytes in the Basic L2CAP mode) and break the
resulting L2CAP PDU into fragments which can then be directly
encapsulated into Data channel PDUs. There are bits in the Data
channel PDUs which identify whether the payload is a complete L2CAP
PDU or the first of a set of fragments, or one of the rest of the
fragments.
There are five L2CAP modes defined in the BT 4.0 spec. These modes
are: Retransmission Mode (a Go-Back-N mechanism is used), Enhanced
Retransmission Mode (includes selective NAK among others), Flow
Control Mode (PDUs are numbered, but there are no retransmissions),
Streaming Mode (PDUs are numbered, but there are no ACKs of any kind)
and Basic L2CAP Mode.
Appendix B. BLUETOOTH Low Energy L2CAP Channel ID Usage for 6LoWPAN/
IPv6
The BT-LE Logical Link Control and Adaptation Protocol (L2CAP) uses
Channel Identifiers (IDs) to distinguish the upper layer protocol
carried on top of it. Two devices exchanging IPv6/6LoWPAN packets
need to use a common Channel ID to be able to send and receive the
packets correctly over L2CAP. It is also important that they avoid
using Channel ID's that conflict with other L2CAP usages. For the
initial use of IPv6/6LoWPAN over BT-LE L2CAP, implementers are
recommended to use Channel ID 0x3E from the BLUETOOTH Special
Interest Group reserved space (BLUETOOTH 4.0 Logical Link Control and
Adaptation Protocol Specification -part, table 2.1 [BTCorev4.0]). As
the IPv6/6LoWPAN use becomes more widely adopted, the BT SIG may
allocate 0x3E or some other Channel ID exclusively for IPv6/6LoWPAN.
Any such BT SIG allocation will deprecate the recommendation given in
this Appendix, and a new RFC will be published at the time of
allocation that will update this RFC and specify the allocated value.
The initial implementers are thus recommended to keep their Channel
ID usage capability flexible to potential future changes.
Authors' Addresses Authors' Addresses
Johanna Nieminen (editor) Johanna Nieminen
Nokia Nokia
Itaemerenkatu 11-13 Itamerenkatu 11-13
FI-00180 Helsinki Helsinki 00180
Finland Finland
Email: johannamaria.nieminen@gmail.com Email: johannamaria.nieminen@gmail.com
Teemu Savolainen
Teemu Savolainen (editor)
Nokia Nokia
Hermiankatu 12 D Hermiankatu 12 D
FI-33720 Tampere Tampere 33720
Finland Finland
Email: teemu.savolainen@nokia.com Email: teemu.savolainen@nokia.com
Markus Isomaki Markus Isomaki
Nokia Nokia
Keilalahdentie 2-4 Keilalahdentie 2-4
FI-02150 Espoo Espoo 02150
Finland Finland
Email: markus.isomaki@nokia.com Email: markus.isomaki@nokia.com
Basavaraj Patil Basavaraj Patil
AT&T AT&T
1410 E. Renner Road 1410 E. Renner Road
Richardson, TX 75082 Richardson, TX 75082
USA USA
Email: basavaraj.patil@att.com Email: basavaraj.patil@att.com
Zach Shelby Zach Shelby
Sensinode Arm
Hallituskatu 13-17D Hallituskatu 13-17D
FI-90100 Oulu Oulu 90100
Finland Finland
Email: zach.shelby@sensinode.com Email: zach.shelby@arm.com
Carles Gomez Carles Gomez
Universitat Politecnica de Catalunya/i2CAT Universitat Politecnica de Catalunya/i2CAT
C/Esteve Terradas, 7 C/Esteve Terradas, 7
Castelldefels 08860 Castelldefels 08860
Spain Spain
Email: carlesgo@entel.upc.edu Email: carlesgo@entel.upc.edu
 End of changes. 85 change blocks. 
407 lines changed or deleted 412 lines changed or added

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