One document matched: draft-ietf-6lowpan-btle-12.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!-- This template is for creating an Internet Draft using xml2rfc,
which is available here: http://xml.resource.org. -->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!-- One method to get references from the online citation libraries.
There has to be one entity for each item to be referenced.
An alternate method (rfc include) is described in the references. -->
<!ENTITY RFC2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY RFC3610 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3610.xml">
<!ENTITY RFC3633 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3633.xml">
<!ENTITY RFC2464 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2464.xml">
<!ENTITY RFC4291 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4291.xml">
<!ENTITY RFC4861 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4861.xml">
<!ENTITY RFC4862 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4862.xml">
<!ENTITY RFC4944 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4944.xml">
<!ENTITY RFC6282 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6282.xml">
<!ENTITY RFC4941 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4941.xml">
<!ENTITY RFC4193 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4193.xml">
<!ENTITY RFC6775 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6775.xml">
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<!-- used by XSLT processors -->
<!-- For a complete list and description of processing instructions (PIs),
please see http://xml.resource.org/authoring/README.html. -->
<!-- Below are generally applicable Processing Instructions (PIs) that most I-Ds might want to use.
(Here they are set differently than their defaults in xml2rfc v1.32) -->
<?rfc strict="no" ?>
<!-- give errors regarding ID-nits and DTD validation -->
<!-- control the table of contents (ToC) -->
<?rfc toc="yes"?>
<!-- generate a ToC -->
<?rfc tocdepth="4"?>
<!-- the number of levels of subsections in ToC. default: 3 -->
<!-- control references -->
<?rfc symrefs="yes"?>
<!-- use symbolic references tags, i.e, [RFC2119] instead of [1] -->
<?rfc sortrefs="yes" ?>
<!-- sort the reference entries alphabetically -->
<!-- control vertical white space
(using these PIs as follows is recommended by the RFC Editor) -->
<?rfc compact="yes" ?>
<!-- do not start each main section on a new page -->
<?rfc subcompact="no" ?>
<!-- keep one blank line between list items -->
<!-- end of list of popular I-D processing instructions -->
<rfc category="std" docName="draft-ietf-6lowpan-btle-12" ipr="trust200902">
<!-- category values: std, bcp, info, exp, and historic
ipr values: trust200902, noModificationTrust200902, noDerivativesTrust200902,
or pre5378Trust200902
you can add the attributes updates="NNNN" and obsoletes="NNNN"
they will automatically be output with "(if approved)" -->
<!-- ***** FRONT MATTER ***** -->
<front>
<!-- The abbreviated title is used in the page header - it is only necessary if the
full title is longer than 39 characters -->
<title abbrev="IPv6 over BT-LE">Transmission of IPv6 Packets over BLUETOOTH Low Energy</title>
<author role="editor" fullname="Johanna Nieminen" initials="J.N" surname="Nieminen">
<organization abbrev="Nokia">Nokia</organization>
<address>
<postal>
<street>Itämerenkatu 11-13</street>
<code>FI-00180 Helsinki</code>
<country>Finland</country>
</postal>
<email>johannamaria.nieminen@gmail.com</email>
</address>
</author>
<author role="editor" initials='T.S' surname="Savolainen" fullname='Teemu Savolainen'>
<organization abbrev="Nokia">Nokia</organization>
<address>
<postal>
<street>Hermiankatu 12 D</street>
<code>FI-33720 Tampere</code>
<country>Finland</country>
</postal>
<email>teemu.savolainen@nokia.com</email>
</address>
</author>
<author initials='M.I.' surname="Isomaki" fullname='Markus Isomaki'>
<organization abbrev="Nokia">Nokia</organization>
<address>
<postal>
<street>Keilalahdentie 2-4</street>
<code>FI-02150 Espoo</code>
<country>Finland</country>
</postal>
<email>markus.isomaki@nokia.com</email>
</address>
</author>
<author initials='B.P' surname="Patil" fullname='Basavaraj Patil'>
<address>
<postal>
<street>6021 Connection drive</street>
<city>Irving</city>
<region>TX</region>
<code>75039</code>
<country>USA</country>
</postal>
<email>bpatil@ovi.com</email>
</address>
</author>
<author initials='Z.S.' surname="Shelby" fullname='Zach Shelby'>
<organization abbrev="Sensinode">Sensinode</organization>
<address>
<postal>
<street>Hallituskatu 13-17D</street>
<code>FI-90100 Oulu</code>
<country>Finland</country>
</postal>
<email>zach.shelby@sensinode.com</email>
</address>
</author>
<author initials='C.G.' surname="Gomez" fullname='Carles Gomez'>
<organization abbrev="Universitat Politecnica de Catalunya/i2CAT">Universitat Politecnica de Catalunya/i2CAT</organization>
<address>
<postal>
<street>C/Esteve Terradas, 7</street>
<code>08860</code>
<city>Castelldefels</city>
<country>Spain</country>
</postal>
<email>carlesgo@entel.upc.edu</email>
</address>
</author>
<date year="2013" />
<!-- Meta-data Declarations -->
<area>Internet</area>
<workgroup>6LoWPAN Working Group</workgroup>
<keyword>Blue Tooth Low Energy</keyword>
<keyword>6lowpan</keyword>
<keyword>IPv6</keyword>
<keyword>Low power</keyword>
<!-- Keywords will be incorporated into HTML output
files in a meta tag but they have no effect on text or nroff
output. If you submit your draft to the RFC Editor, the
keywords will be used for the search engine. -->
<abstract>
<t>
BLUETOOTH Low Energy is a low power air interface technology
defined by the BLUETOOTH Special Interest Group (BT-SIG). The standard BLUETOOTH radio has been
widely implemented and available in mobile phones, notebook
computers, audio headsets and many other devices. The low power
version of BLUETOOTH is a new specification that enables the use of
this air interface with devices such as sensors, smart meters,
appliances, etc. The low power variant of BLUETOOTH is
currently specified in the revision 4.0 of the BLUETOOTH specifications
(BLUETOOTH 4.0). This document describes how IPv6
is transported over BLUETOOTH Low Energy using 6LoWPAN techniques.
</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t>
BLUETOOTH Low Energy (BT-LE) is a radio technology targeted for
devices that operate with coin cell batteries or minimalistic power
sources, which means that low power consumption is essential. BT-LE is an especially attractive technology for
Internet of Things applications, such as health monitors,
environmental sensing, proximity applications and many others.
</t>
<t>
Considering the potential for the exponential growth in the number of sensors and
Internet connected devices and things, IPv6 is
an ideal protocol due to the large address space it provides. In
addition, IPv6 provides tools for stateless address autoconfiguration, which is
particularly suitable for sensor network applications and nodes
which have very limited processing power or lack a full-fledged
operating system.
</t>
<t>
RFC 4944 <xref target="RFC4944"/> specifies the transmission of IPv6 over
IEEE 802.15.4. The BT-LE link in many respects
has similar 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 BT-LE
links. This document specifies the details of IPv6 transmission
over BT-LE links.
</t>
<section title="Terminology and Requirements Language">
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described
in <xref target="RFC2119">RFC 2119</xref>.
</t>
<t>
The terms 6LN, 6LR and 6LBR are defined as in <xref target="RFC6775"/>,
with an addition that BT-LE master and BT-LE slave can both be either 6LN or 6LBR.
</t>
</section>
</section>
<section title="BLUETOOTH Low Energy">
<t>
BT-LE is designed for transferring small amounts of
data infrequently at modest data rates at a very low cost per
bit. BLUETOOTH Special Interest Group has introduced two trademarks, BLUETOOTH Smart for single-mode devices
(a device that only supports BT-LE) and BLUETOOTH Smart Ready for dual-mode devices. In the rest of the
draft, the term BT-LE refers to both types of devices.
</t>
<t>
BT-LE is an integral part of the BT 4.0 specification <xref target="BTCorev4.0"/>. Devices such
as mobile phones, notebooks, tablets and other handheld computing
devices which include BT 4.0 chipsets also
have the low-energy functionality of BLUETOOTH. BT-LE is also
included in many different types of accessories that collaborate with
mobile devices such as phones, tablets and notebook computers. An
example of a use case for a BT-LE accessory is a heart rate monitor
that sends data via the mobile phone to a server on the Internet.
</t>
<section title="BLUETOOTH Low Energy stack">
<t>
The lower layer of the BT-LE stack consists of the Physical (PHY) and
the Link Layer (LL). The Physical Layer transmits and receives the actual
packets. The Link Layer is responsible for providing medium access, connection establishment, error control and flow control. The upper layer consists of the Logical Link Control and
Adaptation Protocol (L2CAP), Generic Attribute protocol (GATT) and
Generic Access Profile (GAP) as shown in <xref target="fig_BTLEStack"/>. GATT and BT-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.
<figure title="BT-LE Protocol Stack"
anchor="fig_BTLEStack">
<artwork><![CDATA[
+----------------------------------------+------------------+
| Applications |
+----------------------------------------+------------------+
| Generic Attribute Profile | Generic Access |
+----------------------------------------+ Profile |
| Attribute Protocol |Security Manager | |
+--------------------+-------------------+------------------+
| Logical Link Control and Adaptation |
+--------------------+-------------------+------------------+
| Host Controller Interface |
+--------------------+-------------------+------------------+
| Link Layer | Direct Test Mode |
+--------------------+-------------------+------------------+
| Physical Layer |
+--------------------+-------------------+------------------+
]]></artwork></figure>
</t>
</section>
<section title="Link layer roles and topology" anchor="llroles">
<t>
BT-LE defines two Link Layer roles: the BT-LE master role and the BT-LE slave
role. A device in the master role, which is called master from now on, can
manage multiple simultaneous connections with a number of devices in
the slave role, called slaves from now on. A slave can only be connected to a
single master. Hence, a BT-LE network (i.e. a BT-LE piconet) follows
a star topology shown in the <xref target="fig_BTLETopo"/>.
This specification primarily addresses the situation where the
slave is a 6LN but not a 6LBR at the IPv6 level.
<figure title="BT-LE Star Topology"
anchor="fig_BTLETopo">
<artwork><![CDATA[
[BT-LE slave]-----\ /-----[BT-LE slave]
\ /
[BT-LE slave]-----+[BT-LE Master]+-----[BT-LE slave]
/ \
[BT-LE slave]-----/ \-----[BT-LE slave]
]]></artwork></figure>
</t>
<t>
A master is assumed to be less constrained than a slave. Hence,
in the primary scenario master and slave will act as 6LoWPAN
Border Router (6LBR) and a 6LoWPAN Node (6LN), respectively.
</t>
<t>
In BT-LE, communication only takes place between a master and a
slave. Hence, in a BT-LE network using IPv6, a radio hop is equivalent
to an IPv6 link and vice versa.
</t>
</section>
<section title="BT-LE device addressing" anchor="deviceaddressing">
<t>
Every BT-LE device is identified by a 48-bit device address. The
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." <xref target="BTCorev4.0"/>.
The public device addresses are based on the IEEE 802-2001 standard <xref target="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.
</t>
</section>
<section title="BT-LE packets sizes and MTU">
<t>
Maximum size of the payload in the BT-LE data channel PDU is 27
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.
</t>
<t>
The maximum IPv6 datagram size that can be transported by L2CAP depends on the L2CAP mode. The Basic L2CAP Mode allows a maximum payload size (i.e. IPv6 datagram size) of 65535 bytes per L2CAP PDU. The rest of the L2CAP modes allow a maximum payload size
that ranges between 65527 and 65533 bytes per L2CAP PDU. <xref target="app-additional"/> describes FAR operation and five L2CAP Modes.
</t>
</section>
</section>
<section title="Specification of IPv6 over BLUETOOTH Low Energy">
<t>
BT-LE technology sets strict requirements for low power consumption
and thus limits the allowed protocol overhead. 6LoWPAN standards
<xref target="RFC4944"/>, <xref target="RFC6775"/>, and <xref target="RFC6282"/> provide useful
functionality for reducing overhead which can be applied to
BT-LE. This functionality comprises of link-local IPv6 addresses and
stateless IPv6 address autoconfiguration (see Section 3.2.1), Neighbor
Discovery (see Section 3.2.2) and header compression (see Section
3.2.3).
</t>
<t>
A significant difference between IEEE 802.15.4 and BT-LE is that the
former supports both star and mesh topology (and requires a routing protocol),
whereas BT-LE does not currently support the formation of
multihop networks at the link layer. In consequence, the mesh header defined in <xref target="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).
</t>
<section title="Protocol stack">
<t>
In order to enable transmission of IPv6 packets over BT-LE, a new
fixed L2CAP Channel Identifier (Channel ID) is to be reserved for IPv6 traffic by the BT-SIG. Until the Channel ID is reserved,
prototype implementations can be implemented as is described in the <xref target="app-additional2"/>.</t>
<t>
<xref target="fig_IPv6overBT-LE"/> 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.
</t>
<t>
<figure title="IPv6 over BT-LE Stack"
anchor="fig_IPv6overBT-LE">
<artwork><![CDATA[
+----------------------------+
| UDP/TCP/other |
+----------------------------+
| IPv6 |
+----------------------------+
| 6LoWPAN adapted to BT-LE |
+----------------------------+
| BT-LE L2CAP |
+----------------------------+
| BT-LE Link Layer |
+----------------------------+
| BT-LE Physical |
+----------------------------+
]]></artwork></figure>
</t>
</section>
<section title="Link model" anchor="linkmodel">
<t>
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 understood in
order to specify the addressing scheme for transmitting IPv6 packets
over the BT-LE link. RFC 4861 <xref target="RFC4861"/> defines a link as "a communication
facility or medium over which nodes can communicate at the link layer,
i.e., the layer immediately below IPv6."
</t>
<t>
In the case of BT-LE, L2CAP is an adaptation layer that supports the
transmission of IPv6 packets. L2CAP also provides multiplexing
capability in addition to FAR functionality.
This specification requires that FAR functionality MUST be provided in
the L2CAP layer. The L2CAP channel characteristics for the transmission
of IPv6 packets on top of BT-LE are the following:</t>
<t>MTU: Equal to or greater than 1280 bytes</t>
<t>Flush Timeout: 0xFFFF (Infinite)</t>
<t>QoS: Best Effort</t>
<t>Mode: Basic Mode</t>
<t>Since FAR in BT-LE is a function of the L2CAP
layer, fragmentation functionality as defined in RFC 4944 <xref target="RFC4944"/> MUST NOT
be used in BT-LE networks. This specification also assumes the IPv6 header compression format specified in RFC 6282 <xref target="RFC6282"/>.
It is also assumed that the IPv6 payload length can be inferred from the L2CAP header length and the IID value inferred, with help of Neighbor Cache, from the link-layer address.
</t>
<t>
The BT-LE link between two communicating nodes can be considered to
be a point-to-point or point-to-multipoint link. When one of the
communicating nodes is in the role of a master, then the link can be
viewed as a point-to-multipoint link from the master point of view.
However, due to BT-LE star topology, each branch of the star is considered
to be an individual link and thus the slaves cannot directly hear
each other and also cannot talk to each other with link-local addresses.
The master ensures address collisions do not occur (see <xref target="neighbordiscovery"/>).
</t>
<t>
After the slave and master have connected at the BT-LE level, the link can be considered up and IPv6 address configuration and transmission can begin.
</t>
<section title="Stateless address autoconfiguration" anchor="slaac">
<t>
A BT-LE 6LN performs stateless address autoconfiguration as per RFC 4862 <xref target="RFC4862"/>.
A 64-bit Interface identifier (IID) for a BT-LE interface MAY be formed by utilizing the 48-bit
BLUETOOTH device address (see <xref target="deviceaddressing"/>) as defined in RFC 2464
"IPv6 over Ethernet" specification <xref target="RFC2464"/>. Alternatively, a randomly generated IID
(see <xref target="neighbordiscovery"/>), MAY be used instead. In the case of randomly
generated IID or randomly generated BLUETOOTH device address, the "Universal/Local" bit MUST
be set to 0 <xref target="RFC4291"/>. Only if the BLUETOOTH device address is known to be
a public address the "Universal/Local" bit can be set to 1.
</t>
<t>
As defined in RFC 4291 <xref target="RFC4291"/>, the IPv6 link-local address for
a BT-LE node is formed by appending the IID, to the prefix FE80::/64,
as depicted in <xref target="fig_IPv6linklocal"/>.
<figure title="IPv6 link-local address in BT-LE"
anchor="fig_IPv6linklocal">
<artwork><![CDATA[
10 bits 54 bits 64 bits
+----------+-----------------+----------------------+
|1111111010| zeros | Interface Identifier |
+----------+-----------------+----------------------+
]]></artwork></figure>
</t>
<t>
The tool for a 6LBR to obtain an IPv6 prefix for numbering the
BT-LE network is out of scope of this document, but can be, for example,
accomplished via DHCPv6 Prefix Delegation <xref target="RFC3633"/> or by
using Unique Local IPv6 Unicast Addresses (ULA) <xref target="RFC4193"/>. Due to the link model of the BT-LE (see <xref target="llroles"/>)
the 6LBR MUST set the "on-link" flag (L) to zero in the
Prefix Information Option <xref target="RFC4861"/>. This will cause 6LNs
to always send packets to the 6LBR, including the case when
the destination is another 6LN using the same prefix.
</t>
</section>
<section title="Neighbor discovery" anchor="neighbordiscovery">
<t>
'Neighbor Discovery Optimization for IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs)' <xref target="RFC6775"/> describes the neighbor discovery approach as adapted for use in several 6LoWPAN topologies, including the mesh topology. BT-LE does not support mesh networks and hence only those aspects that apply to a star topology are considered.
</t>
<t>
The following aspects of the Neighbor Discovery optimizations <xref target="RFC6775"/> are applicable to BT-LE 6LNs:
</t>
<t>
1. A BT-LE 6LN MUST register its address with the 6LBR by sending
a Neighbor Solicitation (NS) message with the ARO option and process the Neighbor Advertisement (NA)
accordingly. The NS with the ARO option SHOULD be sent irrespective
of whether the IID is derived from the unique 48 bit BT-LE device
address or the IID is a random value that is generated as per the
privacy extensions for stateless address autoconfiguration
<xref target="RFC4941"/>. Although RFC 4941 <xref target="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.
</t>
<t>
2. For sending Router Solicitations and processing Router
Advertisements the BT-LE 6LNs MUST, respectively, follow Sections 5.3 and 5.4 of the
<xref target="RFC6775"/>.
</t>
</section>
<section title="Header compression" anchor="hcompression">
<t>
Header compression as defined in RFC 6282 <xref target="RFC6282"/>, which specifies 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 top
of BT-LE. All headers MUST be compressed according to RFC 6282 <xref target="RFC6282"/> encoding formats.
The BT-LE's star topology structure can 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.
</t>
<t>
In a link-local communication, both the IPv6 source and destination
addresses MUST be elided <xref target="RFC6282"/>, since the node knows that the packet is destined for it even if the packet does not have destination IPv6 address. On the other hand, a node SHALL learn the IID of the other endpoint of each L2CAP connection it participates in. By exploiting this information, a node that receives a data channel PDU containing an IPv6 packet (or a part of it) can infer the corresponding IPv6
source address. A node MUST maintain a Neighbor Cache, in which the entries include
both the IID of the neighbor and the Device Address that identifies
the neighbor. For the type of communication considered in this paragraph, the following settings MUST be used in the IPv6 compressed header: CID=0, SAC=0, SAM=11, DAC=0, DAM=11.
</t>
<t>
When a 6LN transmits an IPv6 packet to a remote destination
using global Unicast IPv6 addresses, if a context is defined for the prefix of the 6LNs global IPv6
address, the 6LN MUST indicate this context in the corresponding source fields of the compressed IPv6 header as per
Section 3.1 of RFC 6282 <xref target="RFC6282"/>, and MUST elide the IPv6 source address. For this, the 6LN MUST use the following settings in the IPv6 compressed header: CID=1, SAC=1, SAM=11. In this case, the 6LBR can infer the elided IPv6 source address since 1) the 6LBR has previously
assigned the prefix to the 6LNs; and 2) the 6LBR maintains a
Neighbor Cache that relates the Device Address and the IID of the corresponding slave. If a context is
defined for the IPv6 destination address, the 6LN MUST
also indicate this context in the corresponding destination fields of the compressed IPv6 header, and MUST elide the prefix of the destination IPv6 address. For this, the 6LN MUST set the DAM field of the compressed IPv6 header as DAM=01 (if the context covers a 64-bit prefix)
or as DAM=11 (if the context covers a full, 128-bit address). CID and DAC MUST be set to CID=1 and DAC=1. Note that when a context is defined for the IPv6 destination address, the 6LBR can infer the elided destination prefix by using the context.
</t>
<t>
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 context is defined for the prefix of the 6LN's global IPv6 address, the 6LBR MUST indicate this context in the corresponding destination fields of the compressed IPv6 header, and MUST elide the IPv6 destination
address of the packet before forwarding it to the 6LN. For this, the 6LBR MUST set the DAM field of the IPv6 compressed header as DAM=11. CID and DAC MUST be set to CID=1 and DAC=1. If a context is defined for the prefix of the IPv6 source
address, the 6LBR MUST indicate this context in the source fields of the compressed IPv6 header, and MUST elide that prefix as well.
For this, the 6LBR MUST set the SAM field of the IPv6 compressed header as SAM=01 (if the context covers a 64-bit prefix) or SAM=11 (if the context covers a full, 128-bit address). CID and SAC MUST be set to CID=1 and SAC=1.
</t>
</section>
<section title="Unicast and Multicast address mapping">
<t>
The BT-LE link layer does not support multicast. Hence traffic is
always unicast between two BT-LE nodes. Even in the case where a
master is attached to multiple slaves, the master
cannot do a multicast to all the connected slaves. If the
master needs to send a multicast packet to all its slaves, it has to replicate the packet and unicast it on each link.
However, this may not be energy-efficient and particular care must be taken if the master is battery-powered. In the opposite
direction, a slave can only transmit data to a single destination
(i.e. the master). Hence, when a slave needs to transmit an IPv6 multicast
packet, the slave will unicast the corresponding BT-LE packet to the
master. As described in the <xref target="linkmodel"/> the master
will not forward link-local multicast messages to other slaves
connected to the master.
</t>
</section>
</section>
<section title="Internet connectivity scenarios">
<t>
In a typical scenario, the BT-LE network is connected to the Internet as shown in the <xref target="fig_BTLEInternet"/>.
</t>
<t>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. </t>
<t>
<figure title="BT-LE network connected to the Internet"
anchor="fig_BTLEInternet">
<artwork><![CDATA[
6LN
\ ____________
\ / \
6LN ---- 6LBR --- | Internet |
/ \____________/
/
6LN
<-- BT-LE -->
]]></artwork></figure>
</t>
<t>
In some scenarios, the BT-LE network may transiently or permanently
be an isolated network as shown in the <xref target="fig_BTLENoInternet"/>.
<figure title="Isolated BT-LE network"
anchor="fig_BTLENoInternet">
<artwork><![CDATA[
6LN 6LN
\ /
\ /
6LN --- 6LBR --- 6LN
/ \
/ \
6LN 6LN
<------ BT-LE ----->
]]></artwork></figure>
</t>
<t>
In the isolated network scenario communications between 6LN and 6LBR can use
IPv6 link-local methodology, but for communications between different slaves, the master has to act
as 6LBR, number the network with ULA prefix <xref target="RFC4193"/>, and route packets
between slaves.
</t>
</section>
</section>
<section anchor="IANA" title="IANA Considerations">
<t>
There are no IANA considerations related to this document.
</t>
</section>
<section anchor="Security" title="Security Considerations">
<t>
The transmission of IPv6 over BT-LE links has similar
requirements and concerns for security as for IEEE 802.15.4. IPv6 over BT-LE SHOULD be protected by using BT-LE Link Layer security.
</t>
<t>
BT-LE Link Layer supports encryption and authentication by using the
Counter with CBC-MAC (CCM) mechanism <xref target="RFC3610"/> and a 128-bit AES block cipher. Upper layer security
mechanisms may exploit this functionality when it is available.
(Note: CCM does not consume bytes from the maximum per-packet L2CAP
data size, since the link layer data unit has a specific field for them when they are used.)
</t>
<t>
Key management in BT-LE is provided by the Security Manager Protocol
(SMP), as defined in [BTCorev4.0].
</t>
</section>
<section title="Additional contributors">
<t>
Kanji Kerai, Jari Mutikainen, David Canfeng-Chen and Minjun Xi from
Nokia have contributed significantly to this document.
</t>
</section>
<section anchor="Acknowledgements" title="Acknowledgements">
<t>The BLUETOOTH, BLUETOOTH Smart and BLUETOOTH Smart Ready marks are registred trademarks owned by BLUETOOTH SIG, Inc.</t>
<t>Samita Chakrabarti, Erik Nordmark, and Marcel De Kogel have provided valuable feedback for this draft. </t>
</section>
<!-- <section anchor="Acknowledgements" title="Acknowledgements"> -->
<!-- <t>This template was derived from an initial version written by Pekka -->
<!-- Savola and contributed by him to the xml2rfc project.</t> -->
<!-- </section> -->
<!-- Possibly a 'Contributors' section ... -->
</middle>
<!-- *****BACK MATTER ***** -->
<back>
<!-- References split into informative and normative -->
<!-- There are 2 ways to insert reference entries from the citation libraries:
1. define an ENTITY at the top, and use "ampersand character"RFC2629; here (as shown)
2. simply use a PI "less than character"?rfc include="reference.RFC.2119.xml"?> here
(for I-Ds: include="reference.I-D.narten-iana-considerations-rfc2434bis.xml")
Both are cited textually in the same manner: by using xref elements.
If you use the PI option, xml2rfc will, by default, try to find included files in the same
directory as the including file. You can also define the XML_LIBRARY environment variable
with a value containing a set of directories to search. These can be either in the local
filing system or remote ones accessed by http (http://domain/dir/... ).-->
<references title="Normative References">
<reference anchor="BTCorev4.0">
<front>
<title>BLUETOOTH Specification Version 4.0
</title>
<author>
<organization>BLUETOOTH Special Interest Group</organization>
</author>
<date year="2010" month="June" day="30"/>
</front>
</reference>
<!--?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml"?-->
&RFC2464;
&RFC2119;
&RFC4291;
&RFC4861;
&RFC4862;
&RFC4944;
&RFC6282;
&RFC6775;
</references>
<references title="Informative References">
<!--?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml"?-->
&RFC3610;
&RFC3633;
&RFC4941;
&RFC4193;
<reference anchor="IEEE802-2001">
<front>
<title>IEEE 802-2001 Standard for Local and Metropolitan Area Networks: Overview and Architecture</title>
<author>
<organization>Institute of Electrical and Electronics Engineers (IEEE)</organization>
</author>
<date year="2002"/>
</front>
</reference>
</references>
<section anchor="app-additional" title="BLUETOOTH Low Energy fragmentation and L2CAP Modes">
<t>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.
</t>
<t>
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.
</t>
</section>
<section anchor="app-additional2" title="BLUETOOTH Low Energy L2CAP Channel ID Usage for 6LoWPAN/IPv6">
<t>
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 <xref target="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.
</t>
</section>
<!-- Change Log
v00 2011-03-07 BPa Initial version
-->
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-22 21:47:42 |