rfc9159xml2.original.xml   rfc9159.xml 
<?xml version="1.0" encoding="US-ASCII"?> <?xml version="1.0" encoding="UTF-8"?>
<!-- This template is for creating an Internet Draft using xml2rfc, <!DOCTYPE rfc [
which is available here: http://xml.resource.org. --> <!ENTITY nbsp "&#160;">
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [ <!ENTITY zwsp "&#8203;">
<!-- One method to get references from the online citation libraries. <!ENTITY nbhy "&#8209;">
There has to be one entity for each item to be referenced. <!ENTITY wj "&#8288;">
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 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 RFC4903 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
.4903.xml">
<!ENTITY RFC6282 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
.6282.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">
<!ENTITY RFC7416 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
.7416.xml">
<!ENTITY RFC7668 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
.7668.xml">
<!ENTITY RFC8174 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
.8174.xml">
<!ENTITY RFC8505 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
.8505.xml">
<!ENTITY RFC8928 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
.8928.xml">
<!ENTITY I-D.ietf-6man-default-iids SYSTEM "http://xml.resource.org/public/rfc/b
ibxml3/reference.I-D.ietf-6man-default-iids.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-6lo-blemesh-10" 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 ***** --> <rfc xmlns:xi="http://www.w3.org/2001/XInclude" docName="draft-ietf-6lo-blemesh- 10" number="9159" ipr="trust200902" obsoletes="" updates="" submissionType="IETF " category="std" consensus="true" xml:lang="en" tocInclude="true" tocDepth="4" s ymRefs="true" sortRefs="true" version="3">
<!-- xml2rfc v2v3 conversion 3.9.1 -->
<front> <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 mesh over Bluetooth LE">IPv6 Mesh over BLUETOOTH(R) Low En <title abbrev="IPv6 Mesh over Bluetooth LE">IPv6 Mesh over BLUETOOTH(R) Low En
ergy using IPSP</title> ergy Using the Internet Protocol Support Profile (IPSP)</title>
<seriesInfo name="RFC" value="9159"/>
<author initials='C.G.' surname="Gomez" fullname='Carles Gomez'> <author initials="C." surname="Gomez" fullname="Carles Gomez">
<organization abbrev="Universitat Politecnica de Catalunya">Universitat Poli <organization abbrev="Universitat Politecnica de Catalunya">Universitat Po
tecnica de Catalunya</organization> litecnica de Catalunya</organization>
<address> <address>
<postal> <postal>
<street>C/Esteve Terradas, 7</street> <street>C/Esteve Terradas, 7</street>
<code>08860</code> <code>08860</code>
<city>Castelldefels</city> <city>Castelldefels</city>
<country>Spain</country> <country>Spain</country>
</postal> </postal>
<email>carlesgo@entel.upc.edu</email> <email>carlesgo@entel.upc.edu</email>
</address> </address>
</author> </author>
<author initials="S.M." surname="Darroudi" fullname="Seyed Mahdi Darroudi">
<author initials='S.M.D.' surname="Darroudi" fullname='Seyed Mahdi Darroudi'> <organization abbrev="Universitat Politecnica de Catalunya">Universitat Po
<organization abbrev="Universitat Politecnica de Catalunya">Universitat Poli litecnica de Catalunya</organization>
tecnica de Catalunya</organization> <address>
<address> <postal>
<postal> <street>C/Esteve Terradas, 7</street>
<street>C/Esteve Terradas, 7</street> <code>08860</code>
<code>08860</code> <city>Castelldefels</city>
<city>Castelldefels</city> <country>Spain</country>
<country>Spain</country> </postal>
</postal> <email>sm.darroudi@entel.upc.edu</email>
<email>sm.darroudi@entel.upc.edu</email> </address>
</address> </author>
</author> <author initials="T." surname="Savolainen" fullname="Teemu Savolainen">
<organization abbrev="">Unaffiliated</organization>
<author initials='T.S' surname="Savolainen" fullname='Teemu Savolainen'> <address>
<organization abbrev="">Unaffiliated</organization> <postal>
<address> <street/>
<postal> <city/>
<street></street> <code/>
<city></city> <country/>
<code></code> </postal>
<country></country> <email>tsavo.stds@gmail.com</email>
</postal> </address>
<email>tsavo.stds@gmail.com</email> </author>
</address> <author initials="M." surname="Spoerk" fullname="Michael Spoerk">
</author> <organization abbrev="Graz University of Technology">Graz University of Te
chnology</organization>
<author initials='M.S' surname="Spoerk" fullname='Michael Spoerk'> <address>
<organization abbrev="Graz University of Technology">Graz University of Techn <postal>
ology</organization> <street>Inffeldgasse 16/I</street>
<address> <city>Graz</city>
<postal> <code>8010</code>
<street>Inffeldgasse 16/I</street> <country>Austria</country>
<city>Graz</city> </postal>
<code>8010</code> <email>michael.spoerk@tugraz.at</email>
<country>Austria</country> </address>
</postal> </author>
<email>michael.spoerk@tugraz.at</email> <date year="2021" month="November" />
</address> <area>Internet</area>
</author> <workgroup>6Lo Working Group</workgroup>
<keyword>Bluetooth Low Energy</keyword>
<date year="2021" /> <keyword>mesh networks</keyword>
<keyword>6lowpan</keyword>
<area>Internet</area> <keyword>IPv6</keyword>
<keyword>Low power</keyword>
<workgroup>6Lo Working Group</workgroup> <keyword>IoT</keyword>
<keyword>Internet of Things</keyword>
<keyword>Bluetooth Low Energy</keyword>
<keyword>mesh networks</keyword>
<keyword>6lowpan</keyword>
<keyword>IPv6</keyword>
<keyword>Low power</keyword>
<keyword>IoT</keyword>
<keyword>Internet of Things</keyword>
<abstract> <abstract>
<t> <t>
RFC 7668 describes the adaptation of 6LoWPAN techniques to enable IPv6 over Bluetooth low energy networks that follow the star topology. RFC 7668 describes the adaptation of IPv6 over Low-Power Wireless Perso nal Area Network (6LoWPAN) techniques to enable IPv6 over Bluetooth Low Energy ( Bluetooth LE) networks that follow the star topology.
However, recent Bluetooth specifications allow the formation of extende d topologies as well. This document specifies mechanisms that are needed However, recent Bluetooth specifications allow the formation of extende d topologies as well. This document specifies mechanisms that are needed
to enable IPv6 mesh over Bluetooth Low Energy links established by usin g the Bluetooth Internet Protocol Support Profile. to enable IPv6 mesh over Bluetooth LE links established by using the Bl uetooth Internet Protocol Support Profile (IPSP).
This document does not specify the routing protocol to be used in an IP v6 mesh over Bluetooth LE links. This document does not specify the routing protocol to be used in an IP v6 mesh over Bluetooth LE links.
</t> </t>
</abstract> </abstract>
</front> </front>
<middle>
<middle> <section numbered="true" toc="default">
<section title="Introduction"> <name>Introduction</name>
<t> <t>
Bluetooth Low Energy (hereinafter, Bluetooth LE) was first introduced Bluetooth Low Energy (hereinafter, Bluetooth LE) was first introduced
in the Bluetooth 4.0 specification. Bluetooth LE (which has been in the Bluetooth 4.0 specification. Bluetooth LE (which has been
marketed as Bluetooth Smart) is a low-power wireless technology marketed as Bluetooth Smart) is a low-power wireless technology
designed for short-range control and monitoring applications. designed for short-range control and monitoring applications.
Bluetooth LE is currently implemented in a wide range of consumer Bluetooth LE is currently implemented in a wide range of consumer
electronics devices, such as smartphones and wearable devices. Given electronics devices, such as smartphones and wearable devices. Given
the high potential of this technology for the Internet of Things, the the high potential of this technology for the Internet of Things, the
Bluetooth Special Interest Group (Bluetooth SIG) and the IETF have Bluetooth Special Interest Group (Bluetooth SIG) and the IETF have
produced specifications in order to enable IPv6 over Bluetooth LE, produced specifications in order to enable IPv6 over Bluetooth LE,
such as the Internet Protocol Support Profile (IPSP) [IPSP], and <xref target ="RFC7668">RFC 7668</xref>, respectively. such as the Internet Protocol Support Profile (IPSP) <xref target="IPSP" form at="default"/> and <xref target="RFC7668" format="default">RFC 7668</xref>, resp ectively.
Bluetooth 4.0 only supports Bluetooth LE Bluetooth 4.0 only supports Bluetooth LE
networks that follow the star topology. As a consequence, <xref target="RFC7 668">RFC 7668</xref> was networks that follow the star topology. As a consequence, <xref target="RFC7 668" format="default">RFC 7668</xref> was
specifically developed and optimized for that type of network specifically developed and optimized for that type of network
topology. However, the functionality described in <xref target="RFC7668">RFC 7668</xref> is not topology. However, the functionality described in <xref target="RFC7668" for mat="default">RFC 7668</xref> is not
sufficient and would fail to enable an IPv6 mesh over Bluetooth LE links. Th is sufficient and would fail to enable an IPv6 mesh over Bluetooth LE links. Th is
document specifies mechanisms that are needed to enable IPv6 mesh over Blueto oth LE links. document specifies mechanisms that are needed to enable IPv6 mesh over Blueto oth LE links.
This document does not specify the routing protocol to be used in an This document does not specify the routing protocol to be used in an
IPv6 mesh over Bluetooth LE links. IPv6 mesh over Bluetooth LE links.
</t> </t>
<section numbered="true" toc="default">
<section title="Terminology and Requirements Language"> <name>Terminology and Requirements Language</name>
<t> <t>
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQU
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and IRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
"OPTIONAL" in this NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>
document are to be interpreted as described RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
in BCP14 <xref target="RFC2119">RFC 2119</xref>, <xref target="RFC8174 "<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to
">RFC 8174</xref>, be interpreted as
when, and only when, they appear in all capitals, as shown here. described in BCP&nbsp;14 <xref target="RFC2119"/> <xref target="RFC8174"/>
when, and only when, they appear in all capitals, as shown here.
</t> </t>
<t> <t>
The terms 6LoWPAN Node (6LN), 6LoWPAN Router (6LR) and 6LoWPAN Border Router (6LBR) are defined as in [RFC6775], with an addition that Bluetooth LE ce ntral and Bluetooth LE peripheral (see Section 2) can both be adopted by a 6LN, a 6LR or a 6LBR. The terms "6LoWPAN Node" (6LN), "6LoWPAN Router" (6LR), and "6LoWPAN B order Router" (6LBR) are defined as in <xref target="RFC6775" format="default"/> , with an addition that Bluetooth LE central and Bluetooth LE peripheral (see <x ref target="blue"/>) can both be adopted by a 6LN, a 6LR, or a 6LBR.
</t> </t>
</section> </section>
</section> </section>
<section title="Bluetooth LE Networks and the IPSP"> <section numbered="true" toc="default" anchor="blue">
<t> <name>Bluetooth LE Networks and the IPSP</name>
<t>
Bluetooth LE defines two Generic Access Profile (GAP) roles of relevance herein: the Bluetooth LE central role and the Bluetooth LE peripheral role. Bluetooth LE defines two Generic Access Profile (GAP) roles of relevance herein: the Bluetooth LE central role and the Bluetooth LE peripheral role.
A device in the central role, which is called central from now on, has t In Bluetooth 4.0, a device in the central role, which is called "central" from n
raditionally been able to manage multiple simultaneous connections with a number ow on, was able to manage multiple simultaneous connections with a number of dev
of devices in the peripheral role, ices in the peripheral role,
called peripherals hereinafter. Bluetooth 4.1 (now deprecated) introduce called "peripherals" hereinafter. Bluetooth 4.1 (now deprecated) introdu
d the possibility for a peripheral to be connected to more than one central ced the possibility for a peripheral to be connected to more than one central
simultaneously, therefore allowing extended topologies beyond the star t simultaneously, therefore allowing extended topologies beyond the star t
opology for a Bluetooth LE network. In addition, a device may simultaneously opology for a Bluetooth LE network <xref target="BTCorev4.1"/>. In addition, a d
be a central in a set of link layer connections, as well as a peripheral evice may simultaneously
in others. be a central in a set of link-layer connections, as well as a peripheral
</t> in others.
</t>
<t> <t>
On the other hand, the IPSP enables discovery of IP-enabled devices On the other hand, the IPSP enables discovery of IP-enabled devices
and the establishment of a link layer connection for transporting IPv6 p and the establishment of a link-layer connection for transporting IPv6 p
ackets. The IPSP defines the Node and Router roles for devices that ackets. The IPSP defines the Node and Router roles for devices that
consume/originate IPv6 packets and for devices that can route IPv6 packe consume/originate IPv6 packets and for devices that can route IPv6 packe
ts, respectively. Consistently with Bluetooth 4.1 and subsequent Bluetooth ts, respectively.
versions (e.g. Bluetooth 4.2 [BTCorev4.2] or subsequent), a device may i Consistent with Bluetooth 4.1, Bluetooth 4.2 <xref target="BTCorev4.2" format
mplement both roles simultaneously. ="default"/>, and subsequent Bluetooth versions, a device may implement both rol
</t> es simultaneously.
</t>
<t> <t>
This document assumes a mesh network composed of Bluetooth LE links, whe This document assumes a mesh network composed of Bluetooth LE links, whe
re link layer re link-layer
connections are established between neighboring IPv6-enabled connections are established between neighboring IPv6-enabled
devices (see Section 3.3.2, item 3.b, and an example in Appendix A)). The IP devices (see <xref target="three-b" format="none">Section 3.3.2, item 3.b,</x
v6 forwarding devices of the mesh have to implement both IPSP Node and Router ro ref> and an example in <xref target="Appendix"/>). The IPv6 forwarding devices
les, while simpler leaf-only nodes can implement only the Node role. In an IPv6 of the mesh have to implement both IPSP Node and Router roles, while simpler lea
mesh over Bluetooth LE links, a node is a f-only nodes can implement only the Node role. In an IPv6 mesh over Bluetooth LE
neighbor of another node, and vice versa, if a link layer connection links, a node is a
neighbor of another node, and vice versa, if a link-layer connection
has been established between both by using the IPSP functionality for has been established between both by using the IPSP functionality for
discovery and link layer connection establishment for IPv6 packet discovery and link-layer connection establishment for IPv6 packet
transport. transport.
</t> </t>
</section>
</section> <section numbered="true" toc="default" anchor="spec">
<name>Specification of IPv6 Mesh over Bluetooth LE Links</name>
<section title="Specification of IPv6 mesh over Bluetooth LE links"> <section numbered="true" toc="default">
<section title="Protocol stack"> <name>Protocol Stack</name>
<t> <t>
<xref target="fig_BLEMeshStack"/> illustrates the protocol stack fo <xref target="fig_BLEMeshStack" format="default"/> illustrates the
r IPv6 mesh over Bluetooth LE protocol stack for IPv6 mesh over Bluetooth LE
links. The core Bluetooth LE protocol stack comprises two main sections: the links. The core Bluetooth LE protocol stack comprises two main sections: the
Controller, and the Host. The former includes the Physical Layer, Controller and the Host. The former includes the Physical Layer
and the Link Layer, whereas the latter is composed of the Logical Link Contro l and Adaptation Protocol (L2CAP), the Attribute Protocol (ATT), and the Link Layer, whereas the latter is composed of the Logical Link Contro l and Adaptation Protocol (L2CAP), the Attribute Protocol (ATT),
and the Generic Attribute Profile (GATT). The Host and the Controller section s are connected by means of the Host-Controller Interface (HCI). and the Generic Attribute Profile (GATT). The Host and the Controller section s are connected by means of the Host-Controller Interface (HCI).
A device that supports the IPSP Node role instantiates one Internet Protocol Support Service (IPSS), which runs atop GATT. A device that supports the IPSP Node role instantiates one Internet Protocol Support Service (IPSS), which runs atop GATT.
The protocol stack shown in Figure 1 shows two main differences with the IPv6 The protocol stack shown in <xref target="fig_BLEMeshStack" format="default"/
over > shows two main differences with the IPv6 over
Bluetooth LE stack in RFC 7668: a) the adaptation layer below IPv6 Bluetooth LE stack in <xref target="RFC7668"/>:</t>
(labelled as "6Lo for IPv6 mesh over Bluetooth LE") is now adapted for <ol type="%c)">
IPv6 mesh over Bluetooth LE links, and b) the protocol stack for IPv6 <li>the adaptation layer below IPv6
mesh over Bluetooth LE links includes IPv6 routing functionality. (labeled as "6Lo for IPv6 mesh over Bluetooth LE") is now adapted for
IPv6 mesh over Bluetooth LE links, and</li>
<figure title="Protocol stack for IPv6 mesh over Bluetooth LE links." <li>the protocol stack for IPv6
anchor="fig_BLEMeshStack"> mesh over Bluetooth LE links includes IPv6 routing functionality.</li>
<artwork><![CDATA[ </ol>
<figure anchor="fig_BLEMeshStack">
<name>Protocol Stack for IPv6 Mesh over Bluetooth LE Links</name>
<artwork name="" type="" align="left" alt=""><![CDATA[
+------------------------------------+ +------------------------------------+
| Application | | Application |
+---------+ +------------------------------------+ +---------+ +------------------------------------+
| IPSS | | UDP/TCP/other | | IPSS | | UDP/TCP/other |
+---------+ +------------------------------------+ +---------+ +------------------------------------+
| GATT | | IPv6 |routing| | | GATT | | IPv6 |routing| |
+---------+ +------------------------------------+ +---------+ +------------------------------------+
| ATT | | 6Lo for IPv6 mesh over Bluetooh LE | | ATT | | 6Lo for IPv6 mesh over Bluetooth LE|
+---------+--+------------------------------------+ +---------+--+------------------------------------+
| Bluetooth LE L2CAP | | Bluetooth LE L2CAP |
HCI - - +-------------------------------------------------+ - - HCI - - +-------------------------------------------------+ - -
| Bluetooth LE Link Layer | | Bluetooth LE Link Layer |
+-------------------------------------------------+ +-------------------------------------------------+
| Bluetooth LE Physical Layer | | Bluetooth LE Physical Layer |
+-------------------------------------------------+ +-------------------------------------------------+
]]></artwork></figure> ]]></artwork>
</t> </figure>
<t>Bluetooth 4.2 defines a default MTU for Bluetooth LE of 251 bytes. E
<t>Bluetooth 4.2 defines a default MTU for Bluetooth LE of 251 bytes. Ex xcluding the L2CAP header of 4 bytes, a protocol data unit (PDU)
cluding the L2CAP header of 4 bytes, a protocol data unit (PDU) size of 247 bytes is available for the layer above L2CAP. (Note: Earlier Blue
size of 247 bytes is available for the layer above L2CAP. (Note: earlier Blue tooth LE versions offered a maximum amount of 23 bytes for the layer atop L2CAP.
tooth LE versions offered a maximum amount of 23 bytes for the layer atop L2CAP. )
)
The L2CAP provides a fragmentation and reassembly solution for transmitting o r receiving larger PDUs. At each link, the IPSP defines means for The L2CAP provides a fragmentation and reassembly solution for transmitting o r receiving larger PDUs. At each link, the IPSP defines means for
negotiating a link-layer connection that provides an MTU of 1280 octets or hi gher for the IPv6 layer [IPSP]. negotiating a link-layer connection that provides an MTU of 1280 octets or hi gher for the IPv6 layer <xref target="IPSP"/>.
As per the present specification, the MTU size for IPv6 mesh over BLE links i s 1280 octets. As per the present specification, the MTU size for IPv6 mesh over BLE links i s 1280 octets.
</t> </t>
<t> <t>
Similarly to RFC 7668, fragmentation functionality from 6LoWPAN stan dards is Similarly to <xref target="RFC7668"/>, fragmentation functionality f rom 6LoWPAN standards is
not used for IPv6 mesh over Bluetooth LE links. Bluetooth LE's fragmentation support provided not used for IPv6 mesh over Bluetooth LE links. Bluetooth LE's fragmentation support provided
by L2CAP is used. by L2CAP is used.
</t> </t>
</section> </section>
<section anchor="llroles" numbered="true" toc="default">
<section title="Subnet model" anchor="llroles"> <name>Subnet Model</name>
<t> <t>
For IPv6 mesh over Bluetooth LE links, a multilink model has been For IPv6 mesh over Bluetooth LE links, a multilink model has been
chosen, as further illustrated in Figure 2. As IPv6 over Bluetooth chosen, as further illustrated in <xref target="fig_SubnetModel"/>. As IPv6
LE is intended for constrained nodes, and for Internet of Things use over Bluetooth
LE is intended for constrained nodes and for Internet of Things use
cases and environments, the complexity of implementing a separate cases and environments, the complexity of implementing a separate
subnet on each peripheral-central link and routing between the subnet on each peripheral-central link and routing between the
subnets appears to be excessive. In this specification, the benefits subnets appears to be excessive. In this specification, the benefits
of treating the collection of point-to-point links between a central of treating the collection of point-to-point links between a central
and its connected peripherals as a single multilink subnet rather and its connected peripherals as a single multilink subnet rather
than a multiplicity of separate subnets are considered to outweigh than a multiplicity of separate subnets are considered to outweigh
the multilink model's drawbacks as described in [RFC4903]. the multilink model's drawbacks as described in <xref target="RFC4903" format
With the multilink subnet model, the routers have to take on responsibility f ="default"/>.
or tracking multicast state and forwarding With the multilink subnet model, the routers have to take on the responsibili
ty of tracking the multicast state and forwarding
multicast in a loop-free manner. multicast in a loop-free manner.
Note that the route-over functionality defined in [RFC6775] Note that the route-over functionality defined in <xref target="RFC6775" form
is essential to enable the multilink subnet model for IPv6 mesh over Bluetoot at="default"/>
h LE links. is essential to enabling the multilink subnet model for IPv6 mesh over Blueto
oth LE links.
<figure title="Example of an IPv6 mesh over a Bluetooth LE network connecte </t>
d to the Internet" <figure anchor="fig_SubnetModel">
anchor="fig_SubnetModel"> <name>Example of an IPv6 Mesh over a Bluetooth LE Network Connected to
<artwork><![CDATA[ the Internet</name>
<artwork name="" type="" align="left" alt=""><![CDATA[
/ /
/ /
6LR 6LN 6LN / 6LR 6LN 6LN /
\ \ \ / \ \ \ /
\ \ \ / \ \ \ /
6LN ----- 6LR --------- 6LR ------ 6LBR ----- | Internet 6LN ----- 6LR --------- 6LR ------ 6LBR ----- | Internet
<--Link--> <---Link--->/<--Link->/ | <--Link--> <---Link--->/<--Link->/ |
/ / \ / / \
6LN ---- 6LR ----- 6LR \ 6LN ---- 6LR ----- 6LR \
\ \
\ \
<------------ Subnet -----------------><---- IPv6 connection --> <------------ Subnet -----------------><---- IPv6 connection -->
to the Internet to the Internet
]]></artwork>
]]></artwork></figure> </figure>
</t> <t>
<t>
One or more 6LBRs are connected to the Internet. 6LNs are connected to t he network through a 6LR or a 6LBR. One or more 6LBRs are connected to the Internet. 6LNs are connected to t he network through a 6LR or a 6LBR.
Note that, in some scenarios, and/or for some time intervals, a 6LR may Note that in some scenarios and/or for some time intervals, a 6LR may re
remain at the edge of the network main at the edge of the network
(e.g. the top left node in Figure 2). This may happen when a 6LR has no (e.g., the top left node in <xref target="fig_SubnetModel"/>). This may
neighboring 6LNs. happen when a 6LR has no neighboring 6LNs.
A single Global Unicast prefix is used on the whole subnet. A single global unicast prefix is used on the whole subnet.
</t> </t>
<t> <t>
IPv6 mesh over Bluetooth LE links MUST follow a route-over IPv6 mesh over Bluetooth LE links <bcp14>MUST</bcp14> follow a route-ove
r
approach. This document does not specify the routing protocol to be approach. This document does not specify the routing protocol to be
used in an IPv6 mesh over Bluetooth LE links. used in an IPv6 mesh over Bluetooth LE links.
</t> </t>
</section>
</section> <section anchor="deviceaddressing" numbered="true" toc="default">
<name>Link Model</name>
<section title="Link model" anchor="deviceaddressing"> <section numbered="true" toc="default">
<section title="Stateless address autoconfiguration"> <name>Stateless Address Autoconfiguration</name>
<t> <t>
6LN, 6LR, and 6LBR IPv6 addresses in an IPv6 mesh over Bluetooth LE link s are 6LN, 6LR, and 6LBR IPv6 addresses in an IPv6 mesh over Bluetooth LE link s are
configured as per section 3.2.2 of RFC 7668. configured as per <xref target="RFC7668" sectionFormat="of" section="3.2.2"/>
.
</t>
<t>
Multihop Duplicate Address Detection (DAD) functionality as defined in s
ection 8.2 of RFC 6775 and updated by RFC 8505, or some substitute mechanism (se
e section 3.3.2), MAY be supported.
</t>
</section>
<section title="Neighbor Discovery" anchor="btlemtu"> </t>
<t> <t>
'Neighbor Discovery Optimization for IPv6 over Low-Power Wireless Person Multihop Duplicate Address Detection (DAD) functionality as defined in <
al Area Networks (6LoWPANs)' [RFC6775], subsequently updated xref target="RFC6775" sectionFormat="of" section="8.2"/> and updated by <xref ta
by 'Registration Extensions for IPv6 over Low-Power Wireless Personal A rget="RFC8505"/>, or some substitute mechanism (see <xref target="btlemtu"/>), <
rea Network (6LoWPAN) Neighbor Discovery' [RFC8505], bcp14>MAY</bcp14> be supported.
</t>
</section>
<section anchor="btlemtu" numbered="true" toc="default">
<name>Neighbor Discovery</name>
<t>
"<xref target="RFC6775" format="title"/>" <xref target="RFC6775" format="default
"/>, subsequently updated
by "<xref target="RFC8505" format="title"/>" <xref target="RFC8505" for
mat="default"/>,
describes the neighbor discovery functionality adapted for use in sever al 6LoWPAN topologies, including the mesh topology. describes the neighbor discovery functionality adapted for use in sever al 6LoWPAN topologies, including the mesh topology.
The route-over functionality of RFC 6775 and RFC 8505 MUST be supported The route-over functionality of <xref target="RFC6775"/> and <xref targ
. et="RFC8505"/> <bcp14>MUST</bcp14> be supported.
</t> </t>
<t> <t>
The following aspects of the Neighbor Discovery optimizations for 6LoWPA The following aspects of the Neighbor Discovery optimizations for 6LoWPA
N [RFC6775],[RFC8505] are applicable to Bluetooth LE 6LNs: N <xref target="RFC6775" format="default"/> <xref target="RFC8505" format="defau
</t> lt"/> are applicable to Bluetooth LE 6LNs:
<t> </t>
1. A Bluetooth LE 6LN MUST register its non-link-local addresses with <ol>
<li><t>
A Bluetooth LE 6LN <bcp14>MUST</bcp14> register its non-link-local addre
sses with
its routers by sending a Neighbor Solicitation (NS) message with the Extended Address Registration Option (EARO) and process the its routers by sending a Neighbor Solicitation (NS) message with the Extended Address Registration Option (EARO) and process the
Neighbor Advertisement (NA) accordingly. Neighbor Advertisement (NA) accordingly.
The EARO option includes a Registration Ownership Verifier (ROVR) fi The EARO option includes a Registration Ownership Verifier (ROVR) fi
eld [RFC8505]. In the case of Bluetooth LE, by default the ROVR field eld <xref target="RFC8505" format="default"/>. In the case of Bluetooth LE, by
is filled with the 48-bit device address used by the Bluetooth LE no default, the ROVR field
de converted into 64-bit Modified EUI-64 format [RFC4291]. is filled with the 48-bit device address used by the Bluetooth LE no
Optionally, a cryptographic ID (see <xref target="RFC8928">RFC 8928< de converted into 64-bit Modified EUI-64 format <xref target="RFC4291" format="d
/xref>) MAY be placed in the ROVR field. If a cryptographic ID is used, efault"/>.
address registration and multihop DAD formats and procedures defined Optionally, a cryptographic ID (see <xref target="RFC8928" format="d
in RFC 8928 MUST be used, unless efault">RFC 8928</xref>) <bcp14>MAY</bcp14> be placed in the ROVR field. If a cr
yptographic ID is used,
address registration and multihop DAD formats and procedures defined
in <xref target="RFC8928"/> <bcp14>MUST</bcp14> be used unless
an alternative mechanism offering equivalent protection is used. an alternative mechanism offering equivalent protection is used.
</t> </t>
<t>
<t> As per <xref target="RFC8505"/>, a 6LN link-local address does not need
As per RFC 8505, a 6LN link-local address does not need to be unique in to be unique in the multilink subnet. A link-local address only needs to be uni
the multilink subnet. A link-local address only needs to be unique que
from the perspective of the two nodes that use it to communicate (e.g., the 6LN and the 6LR in an NS/NA exchange). Therefore, the exchange from the perspective of the two nodes that use it to communicate (e.g., the 6LN and the 6LR in an NS/NA exchange). Therefore, the exchange
of EDAR and EDAC messages between the 6LR and a 6LBR, which ensures tha t an address is unique across the domain covered by the 6LBR, does not of Extended Duplicate Address Request (EDAR) and Extended Duplicate Add ress Confirmation (EDAC) messages between the 6LR and a 6LBR, which ensures that an address is unique across the domain covered by the 6LBR, does not
need to take place for link-local addresses. need to take place for link-local addresses.
</t> </t>
<t>
<t>
If the 6LN registers multiple addresses that are not based on the If the 6LN registers multiple addresses that are not based on the
Bluetooth device address using the same compression context, the Bluetooth device address using the same compression context, the
header compression efficiency may decrease, since only the last registered ad header compression efficiency may decrease, since only the last registered ad
dress can be fully elided (see Section 3.2.4 of RFC 7668). dress can be fully elided (see <xref target="RFC7668" sectionFormat="of" section
</t> ="3.2.4"/>).
</t></li>
<t> <li><t>
2. For sending Router Solicitations and processing Router Advertisements, For sending Router Solicitations and processing Router Advertisements, the
the hosts that participate in an IPv6 mesh over BLE MUST, respectively, follow S hosts that participate in an IPv6 mesh over BLE <bcp14>MUST</bcp14>, respectivel
ections 5.3 and 5.4 y, follow Sections <xref target="RFC6775" sectionFormat="bare" section="5.3"/> a
of [RFC6775], and Section 5.6 of [RFC8505]. nd <xref target="RFC6775" sectionFormat="bare" section="5.4"/>
</t> of <xref target="RFC6775" format="default"/>, and <xref target="RFC8505
<t> " sectionFormat="of" section="5.6"/>.
3. The router behavior for 6LRs and 6LBRs is described in Section 6 of RFC </t></li>
6775, and updated by RFC 8505. However, as per this specification: <li><t>
The router behavior for 6LRs and 6LBRs is described in <xref target="RFC677
a) Routers SHALL NOT use multicast NSs to discover other routers' link 5" sectionFormat="of" section="6"/> and updated by <xref target="RFC8505"/>. How
layer addresses. ever, as per this specification:
</t><ol type="a">
<li>Routers <bcp14>SHALL NOT</bcp14> use multicast NSs to discover othe
r routers' link-layer addresses.</li>
b) As per section 6.2 of RFC 6775, in a dynamic configuration scenario, <li anchor="three-b">As per <xref target="RFC6775" sectionFormat="of" se
a 6LR comes up as a non-router and waits to receive a Router Advertisement ction="6.2"/>, in a dynamic configuration scenario, a 6LR comes up as a non-rout
for configuring its own interface address first, before setting its i er and waits to receive a Router Advertisement
nterfaces to be advertising interfaces and turning into a router. for configuring its own interface address first before setting its in
In order to support such operation in an IPv6 mesh over Bluetooth LE terfaces to advertising interfaces and turning into a router.
links, a 6LR first uses the IPSP Node role only. Once the 6LR has established In order to support such an operation in an IPv6 mesh over Bluetooth
a connection with another node currently running as a router, and rec LE links, a 6LR first uses the IPSP Node role only. Once the 6LR has established
eives a Router Advertisement from that router, the 6LR configures its own a connection with another node currently running as a router and rece
interface address, it turns into a router, and it runs as an IPSP Rou ives a Router Advertisement from that router, the 6LR configures its own
ter. In contrast with a 6LR, a 6LBR uses the IPSP Router role since the 6LBR interface address, turns into a router, and runs as an IPSP Router. I
is initialized, that is, the 6LBR uses both the IPSP Node and IPSP Ro n contrast with a 6LR, a 6LBR uses the IPSP Router role since the 6LBR
uter roles at all times. See an example in Appendix B.. is initialized; that is, the 6LBR uses both the IPSP Node and IPSP Ro
</t> uter roles at all times. See an example in <xref target="Appendix_B"/>.</li>
<t> </ol></li>
4. Border router behavior is described in Section 7 of RFC 6775, and updat <li><t>
ed by RFC 8505. Border router behavior is described in <xref target="RFC6775" sectionFormat
</t> ="of" section="7"/> and updated by <xref target="RFC8505"/>.
<t> </t>
RFC 6775 defines substitutable mechanisms for distributing prefixes and c <t>
ontext information (section 8.1 of RFC 6775), as well as for <xref target="RFC6775"/> defines substitutable mechanisms for distributin
Duplicate Address Detection across a route-over 6LoWPAN (section 8.2 of R g prefixes and context information (<xref target="RFC6775" sectionFormat="of" se
FC 6775). RFC 8505 updates those mechanisms and the related message formats. ction="8.1"/>), as well as for
Implementations of this specification MUST either support the features de duplicate address detection across a route-over 6LoWPAN (<xref target="RF
scribed in sections 8.1 and 8.2 of RFC 6775, as updated by RFC 8505, C6775" sectionFormat="of" section="8.2"/>). <xref target="RFC8505"/> updates tho
se mechanisms and the related message formats.
Implementations of this specification <bcp14>MUST</bcp14> either support
the features described in Sections <xref target="RFC6775" sectionFormat="bare" s
ection="8.1"/> and <xref target="RFC6775" sectionFormat="bare" section="8.2"/> o
f <xref target="RFC6775"/>, as updated by <xref target="RFC8505"/>
or some alternative ("substitute") mechanism. or some alternative ("substitute") mechanism.
</t> </t></li>
</section> </ol>
</section>
<section title="Header compression" anchor="hc"> <section anchor="hc" numbered="true" toc="default">
<t> <name>Header Compression</name>
Header compression as defined in RFC 6282 [RFC6282], which specifies the <t>
compression format for IPv6 datagrams on top of IEEE 802.15.4, is REQUIRED as t Header compression as defined in RFC 6282 <xref target="RFC6282" format=
he basis for IPv6 header compression on top of Bluetooth LE. All headers MUST be "default"/>, which specifies the compression format for IPv6 datagrams on top of
compressed according to RFC 6282 [RFC6282] encoding formats. IEEE 802.15.4, is <bcp14>REQUIRED</bcp14> as the basis for IPv6 header compress
</t> ion on top of Bluetooth LE. All headers <bcp14>MUST</bcp14> be compressed accord
<t> ing to RFC 6282 <xref target="RFC6282" format="default"/> encoding formats.
To enable efficient header compression, when the 6LBR sends a Router Adv </t>
ertisement it MAY include a 6LoWPAN Context Option (6CO) [RFC6775] <t>
matching each address prefix advertised via a Prefix Information Option To enable efficient header compression, when the 6LBR sends a Router Adv
(PIO) [RFC4861] for use in stateless address autoconfiguration. ertisement, it <bcp14>MAY</bcp14> include a 6LoWPAN Context Option (6CO) <xref t
Note that 6CO is not needed for context-based compression when context i arget="RFC6775" format="default"/>
s pre-provisioned or provided by out-of-band means, matching each address prefix advertised via a Prefix Information Option
as in these cases the in-band indication (6CO) becomes superfluous. (PIO) <xref target="RFC4861" format="default"/> for use in stateless address aut
oconfiguration.
Note that 6CO is not needed for context-based compression when the conte
xt is pre-provisioned or provided by out-of-band means
as, in these cases, the in-band indication (6CO) becomes superfluous.
</t> </t>
<t> <t>
The specific optimizations of RFC 7668 for header compression, which The specific optimizations of <xref target="RFC7668"/> for header compre
exploited the star topology and ARO (note that the latter has been updated by ssion, which
EARO as per RFC 8505), cannot be generalized in an IPv6 exploited the star topology and Address Registration Option (ARO) (note that
the latter has been updated by EARO as per <xref target="RFC8505"/>), cannot be
generalized in an IPv6
mesh over Bluetooth LE links. Still, a subset of those optimizations mesh over Bluetooth LE links. Still, a subset of those optimizations
can be applied in some cases in such a network. These cases comprise link-lo cal interactions, non-link-local packet can be applied in some cases in such a network. These cases comprise link-lo cal interactions, non-link-local packet
transmissions originated by a 6LN (i.e. the first hop from a 6LN), and non-li nk-local transmissions originated by a 6LN (i.e., the first hop from a 6LN), and non-l ink-local
packets intended for a 6LN that are originated or forwarded by a neighbor packets intended for a 6LN that are originated or forwarded by a neighbor
of that 6LN (i.e. the last hop toward a 6LN). For all other packet transmiss of that 6LN (i.e., the last hop toward a 6LN). For all other packet transmis
ions, context-based compression MAY be used. sions, context-based compression <bcp14>MAY</bcp14> be used.
</t>
<t>
When a device transmits a packet to a neighbor, the sender MUST fully el
ide the source IID if the source IPv6 address is the link-local address based on
the sender's Bluetooth device address (SAC=0, SAM=11). The sender also MUST ful
ly elide the destination IPv6 address if it is the link-local address based on t
he neighbor's Bluetooth device address (DAC=0, DAM=11).
</t>
<t> </t>
When a 6LN transmits a packet, with a non-link-local source address <t>
When a device transmits a packet to a neighbor, the sender <bcp14>MUST</
bcp14> fully elide the source Interface Identifier (IID) if the source IPv6 addr
ess is the link-local address based on the sender's Bluetooth device address (SA
C=0, SAM=11). The sender also <bcp14>MUST</bcp14> fully elide the destination IP
v6 address if it is the link-local address based on the neighbor's Bluetooth dev
ice address (DAC=0, DAM=11).
</t>
<t>
When a 6LN transmits a packet with a non-link-local source address
that the 6LN has registered with EARO in the next-hop router for the that the 6LN has registered with EARO in the next-hop router for the
indicated prefix, the source address MUST be fully elided if it is indicated prefix, the source address <bcp14>MUST</bcp14> be fully elided if i t is
the latest address that the 6LN has registered for the indicated the latest address that the 6LN has registered for the indicated
prefix (SAC=1, SAM=11). If the source non-link-local address is not prefix (SAC=1, SAM=11).
the latest registered by the 6LN, and the first 48 bits of the IID match If the source non-link-local address is not
with the latest address registered by the 6LN, then the last 16 bits of the I the latest registered by the 6LN and the first 48 bits of the IID match
ID the latest address are registered by the 6LN, then the last 16 bits of the II
SHALL be carried in-line (SAC=1, SAM=10). Otherwise, if the first 48 bits of D
the IID do not match, <bcp14>SHALL</bcp14> be carried inline (SAC=1, SAM=10). Otherwise, if the fir
then the 64 bits of the IID SHALL be fully carried in-line (SAC=1, SAM=01). st 48 bits of the IID do not match,
then the 64 bits of the IID <bcp14>SHALL</bcp14> be fully carried inline (SAC
=1, SAM=01).
</t> </t>
<t> <t>
When a router transmits a packet to a neighboring 6LN, with a non- When a router transmits a packet to a neighboring 6LN with a non-link-loc
link-local destination address, the router MUST fully elide the al destination address, the router <bcp14>MUST</bcp14> fully elide the
destination IPv6 address if the destination address is the latest destination IPv6 address if the destination address is the latest
registered by the 6LN with EARO for the indicated context (DAC=1, registered by the 6LN with EARO for the indicated context (DAC=1,
DAM=11). If the destination address is a non-link-local address and DAM=11). If the destination address is a non-link-local address and
not the latest registered, and the first 48 bits of the IID match to those of not the latest registered and if the first 48 bits of the IID match those of
the latest registered address, the latest registered address,
then the last 16 bits of the IID SHALL be carried in-line (DAC=1, DAM=10). Ot then the last 16 bits of the IID <bcp14>SHALL</bcp14> be carried inline (DAC=
herwise, if the first 48 bits of the IID do not match, 1, DAM=10). Otherwise, if the first 48 bits of the IID do not match,
then the 64 bits of the IID SHALL be fully carried in-line (DAC=1, DAM=01). then the 64 bits of the IID <bcp14>SHALL</bcp14> be fully carried in-line (DA
</t> C=1, DAM=01).
</section> </t>
<section title="Unicast and multicast mapping"> </section>
<t> <section numbered="true" toc="default">
<name>Unicast and Multicast Mapping</name>
<t>
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 neighboring nodes. traffic is always unicast between two Bluetooth LE neighboring nodes.
If a node needs to send a multicast packet to several neighbors, it has If a node needs to send a multicast packet to several neighbors, it has
to replicate the packet and unicast it on each link. However, this may 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 node not be energy efficient, and particular care must be taken if the node
is battery powered. A router (i.e., a 6LR or a 6LBR) MUST keep track is battery powered. A router (i.e., a 6LR or a 6LBR) <bcp14>MUST</bcp14> kee
of neighboring multicast listeners, and it MUST NOT forward multicast p track
of neighboring multicast listeners, and it <bcp14>MUST NOT</bcp14> forward mu
lticast
packets to neighbors that have not registered as listeners for multicast grou ps to which the packets are destined. packets to neighbors that have not registered as listeners for multicast grou ps to which the packets are destined.
</t> </t>
</section> </section>
</section> </section>
</section> </section>
<section anchor="IANA" numbered="true" toc="default">
<section anchor="IANA" title="IANA Considerations"> <name>IANA Considerations</name>
<t> <t>
There are no IANA considerations related to this document. This document has no IANA actions.
</t> </t>
</section> </section>
<section anchor="Security" numbered="true" toc="default">
<section anchor="Security" title="Security Considerations"> <name>Security Considerations</name>
<t> <t>
The security considerations in RFC 7668 apply. The security considerations in <xref target="RFC7668"/> apply.
</t> </t>
<t> <t>
IPv6 mesh over Bluetooth LE links requires a routing protocol to IPv6 mesh over BLE requires a routing protocol to
find end-to-end paths. Unfortunately, the routing protocol may find end-to-end paths. Unfortunately, the routing protocol may
generate additional opportunities for threats and attacks to the generate additional opportunities for threats and attacks to the
network. network.
</t> </t>
<t>
<t> <xref target="RFC7416" format="default">RFC 7416</xref> provides a systemat
<xref target="RFC7416">RFC 7416</xref> provides a systematic overview of th ic overview of threats and
reats and
attacks on the IPv6 Routing Protocol for Low-Power and Lossy Networks attacks on the IPv6 Routing Protocol for Low-Power and Lossy Networks
(RPL), as well as countermeasures. In that document, described threats and at tacks comprise threats due to failures to authenticate, threats due to failure t o keep routing information, threats and attacks on integrity, and threats and at tacks on availability. Reported countermeasures comprise (RPL), as well as countermeasures. In that document, described threats and at tacks comprise threats due to failures to authenticate, threats due to failure t o keep routing information, threats and attacks on integrity, and threats and at tacks on availability. Reported countermeasures comprise
confidentiality attack, integrity attack, and availability attack countermeasure s. confidentiality attack, integrity attack, and availability attack countermeasure s.
</t> </t>
<t> <t>
While this specification does not While this specification does not
state the routing protocol to be used in IPv6 mesh over Bluetooth LE state the routing protocol to be used in IPv6 mesh over Bluetooth LE
links, the guidance of RFC 7416 is useful when RPL is used in links, the guidance of <xref target="RFC7416"/> is useful when RPL is used in
such scenarios. Furthermore, such guidance may partly apply for such scenarios. Furthermore, such guidance may partly apply for
other routing protocols as well. other routing protocols as well.
</t> </t>
<t>
<t>
The ROVR can be derived from the Bluetooth device address. However, such a ROVR can be The ROVR can be derived from the Bluetooth device address. However, such a ROVR can be
spoofed, and therefore, any node connected to the subnet and aware of spoofed; therefore, any node connected to the subnet and aware of
a registered-address-to-ROVR mapping could perform address theft and a registered-address-to-ROVR mapping could perform address theft and
impersonation attacks. Use of Address Protected Neighbor Discovery <xref targ et="RFC8928">RFC 8928</xref> provides protection impersonation attacks. Use of Address Protected Neighbor Discovery <xref targ et="RFC8928" format="default"/> provides protection
against such attacks. against such attacks.
</t> </t>
</section>
</section> </middle>
<back>
<section anchor="Contrib" title="Contributors">
<t>
Carlo Alberto Boano (Graz University of Technology) contributed to the des
ign and validation of this document.
</t>
</section>
<section anchor="Acknowledgements" title="Acknowledgements"> <references>
<t> <name>References</name>
The Bluetooth, Bluetooth Smart and Bluetooth Smart Ready marks are registe <references>
red trademarks owned by Bluetooth SIG, Inc. <name>Normative References</name>
</t>
<t> <reference anchor="IPSP" target="https://www.bluetooth.com/specification
The authors of this document are grateful to all RFC 7668 authors, since t s/specs/internet-protocol-support-profile-1-0/">
his document borrows many concepts (albeit, with necessary extensions) from RFC <front>
7668. <title>Internet Protocol Support Profile 1.0</title>
</t> <author>
<organization>Bluetooth</organization>
</author>
<date year="2014" month="December" day="16"/>
</front>
</reference>
<t> <reference anchor="BTCorev4.2" target="https://www.bluetooth.com/specific
The authors also thank Alain Michaud, Mark Powell, Martin Turon, Bilhanan ations/specs/core-specification-4-2/">
Silverajan, Rahul Jadhav, Pascal Thubert, Acee Lindem, Catherine Meadows, <front>
and Dominique Barthel for their reviews and comments, which helped improve <title>Core Specification 4.2</title>
the document. <author>
</t> <organization>Bluetooth</organization>
</author>
<date year="2014" month="December" day="2"/>
</front>
</reference>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.2119.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.4291.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.4861.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.6282.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.6775.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.7668.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.8505.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.8174.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.8928.xml"/>
</references>
<references>
<name>Informative References</name>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.4903.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.7416.xml"/>
<t> <reference anchor="BTCorev4.1" target="https://www.bluetooth.com/specifi
Carles Gomez has been supported in part by the Spanish Government Minister cations/specs/core-specification-4-1/">
io de Economia y Competitividad through projects TEC2012-32531, <front>
TEC2016-79988-P, PID2019-106808RA-I00 and FEDER, and Secretaria d'Universi <title>Core Specification 4.1</title>
tats i Recerca del Departament d'Empresa i Coneixement de la Generalitat <author>
de Catalunya 2017 through grant SGR 376. <organization>Bluetooth</organization>
</t> </author>
</section> <date year="2013" month="December" day="3"/>
</front>
</reference>
</references>
</references>
<section anchor="Appendix" title="Appendix A: Bluetooth LE connection establishm <section anchor="Appendix" numbered="true" toc="default">
ent example"> <name>Bluetooth LE Connection Establishment Example</name>
<t>
This appendix provides an example of Bluetooth LE connection establishment
and use of IPSP roles in an IPv6 mesh over Bluetooth LE links that uses dynamic
configuration. The example follows text in Section 3.3.2, item 3.b).
</t>
<t>
The example assumes a network with one 6LBR, two 6LRs and three 6LNs, as s
hown in <xref target="fig_Appendix"/>. Connectivity between the 6LNs and the 6LB
R is only possible via the 6LRs.
</t>
<t>
The following text describes the different steps as time evolves, in the e
xample. Note that other sequences of events that may lead to the same final scen
ario are also possible.
</t>
<t> <t>
At the beginning, the 6LBR starts running as an IPSP Router, whereas the r This appendix provides an example of Bluetooth LE connection establishment
est of devices are not yet initialized (Step 1). Next, the 6LRs start running as and use of IPSP roles in an IPv6 mesh over BLE that uses dynamic configuration.
IPSP Nodes, i.e., they use Bluetooth LE advertisement packets to announce their The example follows text in <xref target="three-b" format="none">Section 3.3.2,
presence and support of IPv6 capabilities (Step 2). item 3.b</xref>.
The 6LBR (already running as an IPSP Router) discovers the presence of the </t>
6LRs and establishes one Bluetooth LE connection with each 6LR (Step 3). After <t>
establishment of those link layer connections (and after reception of Router Adv The example assumes a network with one 6LBR, two 6LRs, and three 6LNs, as
ertisements from the 6LBR), shown in <xref target="fig_Appendix" format="default"/>. Connectivity between th
the 6LRs start operating as routers, and also initiate the IPSP Router rol e 6LNs and the 6LBR is only possible via the 6LRs.
e (Step 4) (note: whether the IPSP Node role is kept running simultaneously is a </t>
n implementation decision). Then, 6LNs start running the IPSP Node role (Step 5) <t>
. The following text describes the different steps in the example as time ev
Finally, the 6LRs discover presence of the 6LNs and establish connections olves. Note that other sequences of events that may lead to the same final scena
with the latter (Step 6). rio are also possible.
</t> </t>
<t>
<figure title="An example of connection establishment and use of IPSP roles i At the beginning, the 6LBR starts running as an IPSP router, whereas the r
n an IPv6 mesh over Bluetooth LE links." est of devices are not yet initialized (<xref target="step1" format="none">Step
anchor="fig_Appendix"> 1</xref>). Next, the 6LRs start running as IPSP nodes, i.e., they use Bluetooth
<artwork><![CDATA[ LE advertisement packets to announce their presence and support of IPv6 capabili
ties (<xref target="step2" format="none">Step 2</xref>).
The 6LBR (already running as an IPSP router) discovers the presence of the
6LRs and establishes one Bluetooth LE connection with each 6LR (<xref target="s
tep3" format="none">Step 3</xref>). After establishment of those link-layer conn
ections (and after reception of Router Advertisements from the 6LBR),
the 6LRs start operating as routers and also initiate the IPSP Router role
(<xref target="step4" format="none">Step 4</xref>). (Note: whether the IPSP Nod
e role is kept running simultaneously is an implementation decision). Then, 6LNs
start running the IPSP Node role (<xref target="step5" format="none">Step 5</xr
ef>).
Finally, the 6LRs discover the presence of the 6LNs and establish connecti
ons with the latter (<xref target="step6" format="none">Step 6</xref>).
</t>
<figure anchor="fig_Appendix">
<name>Example of Connection Establishment and Use of IPSP Roles in an IP
v6 Mesh over Bluetooth LE Links</name>
<artwork anchor="step1" name="" type="" align="left" alt=""><![CDATA[
Step 1 Step 1
****** ******
6LBR 6LBR
(IPSP: Router) (IPSP: Router)
6LR 6LR 6LR 6LR
(not initialized) (not initialized) (not initialized) (not initialized)
6LN 6LN 6LN 6LN 6LN 6LN
(not initialized) (not initialized) (not initialized) (not initialized) (not initialized) (not initialized)
]]></artwork>
<artwork anchor="step2" name="" type="" align="left" alt=""><![CDATA[
Step 2 Step 2
****** ******
6LBR 6LBR
(IPSP: Router) (IPSP: Router)
6LR 6LR 6LR 6LR
(IPSP: Node) (IPSP: Node) (IPSP: Node) (IPSP: Node)
6LN 6LN 6LN 6LN 6LN 6LN
(not initialized) (not initialized) (not initialized) (not initialized) (not initialized) (not initialized)
]]></artwork>
<artwork anchor="step3" name="" type="" align="left" alt=""><![CDATA[
Step 3 Step 3
****** ******
6LBR 6LBR
(IPSP: Router) (IPSP: Router)
Bluetooth LE connection --> / \ Bluetooth LE connection --> / \
/ \ / \
6LR 6LR 6LR 6LR
(IPSP: Node) (IPSP: Node) (IPSP: Node) (IPSP: Node)
6LN 6LN 6LN 6LN 6LN 6LN
(not initialized) (not initialized) (not initialized) (not initialized) (not initialized) (not initialized)
]]></artwork>
<artwork anchor="step4" name="" type="" align="left" alt=""><![CDATA[
Step 4 Step 4
****** ******
6LBR 6LBR
(IPSP: Router) (IPSP: Router)
/ \ / \
/ \ / \
6LR 6LR 6LR 6LR
(IPSP: Router) (IPSP: Router) (IPSP: Router) (IPSP: Router)
6LN 6LN 6LN 6LN 6LN 6LN
(not initialized) (not initialized) (not initialized) (not initialized) (not initialized) (not initialized)
]]></artwork>
<artwork anchor="step5" name="" type="" align="left" alt=""><![CDATA[
Step 5 Step 5
****** ******
6LBR 6LBR
(IPSP: Router) (IPSP: Router)
/ \ / \
/ \ / \
6LR 6LR 6LR 6LR
(IPSP: Router) (IPSP: Router) (IPSP: Router) (IPSP: Router)
6LN 6LN 6LN 6LN 6LN 6LN
(IPSP: Node) (IPSP: Node) (IPSP: Node) (IPSP: Node) (IPSP: Node) (IPSP: Node)
]]></artwork>
<artwork anchor="step6" name="" type="" align="left" alt=""><![CDATA[
Step 6 Step 6
****** ******
6LBR 6LBR
(IPSP: Router) (IPSP: Router)
/ \ / \
/ \ / \
6LR 6LR 6LR 6LR
(IPSP: Router) (IPSP: Router) (IPSP: Router) (IPSP: Router)
/ \ / \ / \ / \
/ \ / \ / \ / \
/ \ / \ / \ / \
6LN 6LN 6LN 6LN 6LN 6LN
(IPSP: Node) (IPSP: Node) (IPSP: Node) (IPSP: Node) (IPSP: Node) (IPSP: Node)
]]></artwork>
]]></artwork></figure> </figure>
</section>
</section> <section anchor="Appendix_B" numbered="true" toc="default">
<name>Node-Joining Procedure</name>
<section anchor="Appendix_B" title="Appendix B: Node joining procedure"> <t>
<t> This appendix provides a diagram that illustrates the node-joining procedu
This appendix provides a diagram that illustrates the node joining procedu re. First of all, the joining node advertises its presence in order to allow est
re. First of all, the joining node advertises its presence in order to allow est ablishment of Bluetooth LE connections with neighbors that already belong to a n
ablishing Bluetooth LE connections with neighbors that already belong to a netwo etwork. The neighbors typically run as a 6LR or as a 6LBR. After Bluetooth LE co
rk. The latter typically run as a 6LR or as a 6LBR. After Bluetooth LE connectio nnection establishment, the joining node starts acting as a 6LN.
n establishment, the joining node starts acting as a 6LN. </t>
</t> <t><xref target="fig_AppendixB" format="default"/> shows the sequence of m
essages that are exchanged by the 6LN and a neighboring 6LR that already belongs
<t><xref target="fig_AppendixB"/> shows the sequence of messages that are exc to the network after the establishment of a Bluetooth LE connection between bot
hanged by the 6LN and a neighboring 6LR that already belongs to the network, h devices. Initially, the 6LN sends a Router Solicitation (RS) message (1). Then
after the establishment of a Bluetooth LE connection between both devices. , the 6LR replies
Initially, the 6LN sends an RS message (1). Then, the 6LR replies with an RA, which includes the PIO (2). After discovering the non-link-loc
with an RA, which includes the PIO (2). After discovering the non-link-loc al prefix in use in the network, the 6LN creates its non-link-local address and
al prefix in use in the network, the 6LN creates its non-link-local address, reg registers that address with EARO (3) in the 6LR, and then multihop DAD is perfor
isters that address with EARO (3) in the 6LR, and multihop DAD is performed (4). med (4).
The next step is the transmission of the NA message sent by the 6LR in res ponse to the NS previously sent by the 6LN (5). The next step is the transmission of the NA message sent by the 6LR in res ponse to the NS previously sent by the 6LN (5).
If the non-link-local address of the 6LN has been successfully validated, the 6LN can operate as a member of the network it has joined. If the non-link-local address of the 6LN has been successfully validated, the 6LN can operate as a member of the network it has joined.
</t> </t>
<figure anchor="fig_AppendixB">
<figure title="Message exchange diagram for a joining node" <name>Message Exchange Diagram for a Joining Node</name>
anchor="fig_AppendixB"> <artwork name="" type="" align="left" alt=""><![CDATA[
<artwork><![CDATA[
(1) 6LN ----(RS)-------> 6LR (1) 6LN ----(RS)-------> 6LR
(2) 6LN <---(RA-PIO)---- 6LR (2) 6LN <---(RA-PIO)---- 6LR
(3) 6LN ----(NS-EARO)--> 6LR (3) 6LN ----(NS-EARO)--> 6LR
(4) [Multihop DAD procedure] (4) [Multihop DAD procedure]
(5) 6LN <---(NA)-------- 6LR (5) 6LN <---(NA)-------- 6LR
]]></artwork>
</figure>
</section>
]]></artwork></figure> <section anchor="Acknowledgements" numbered="false" toc="default">
<name>Acknowledgements</name>
</section> <t>
The Bluetooth, Bluetooth Smart, and Bluetooth Smart Ready marks are regist
</middle> ered trademarks owned by Bluetooth SIG, Inc.
</t>
<back> <t>
<!-- References split into informative and normative --> The authors of this document are grateful to all authors of <xref target="
RFC7668"/>, since this document borrows many concepts (albeit with necessary ext
<!-- There are 2 ways to insert reference entries from the citation libraries ensions) from <xref target="RFC7668"/>.
: </t>
1. define an ENTITY at the top, and use "ampersand character"RFC2629; here ( <t>
as shown) The authors also thank <contact fullname="Alain Michaud"/>, <contact ful
2. simply use a PI "less than character"?rfc include="reference.RFC.2119.xml lname="Mark Powell"/>, <contact fullname="Martin Turon"/>, <contact fullname="
"?> here Bilhanan Silverajan"/>, <contact fullname="Rahul Jadhav"/>, <contact fullname=
(for I-Ds: include="reference.I-D.narten-iana-considerations-rfc2434bis.x "Pascal Thubert"/>, <contact fullname="Acee Lindem"/>, <contact fullname="Cath
ml") erine Meadows"/>,
and <contact fullname="Dominique Barthel"/> for their reviews and comment
Both are cited textually in the same manner: by using xref elements. s, which helped improve the document.
If you use the PI option, xml2rfc will, by default, try to find included fil </t>
es in the same <t>
directory as the including file. You can also define the XML_LIBRARY environ <contact fullname="Carles Gomez"/> has been supported in part by the Span
ment variable ish Government Ministerio de Economia y Competitividad through projects TEC2012-
with a value containing a set of directories to search. These can be either 32531,
in the local TEC2016-79988-P, PID2019-106808RA-I00, and FEDER and Secretaria d'Universi
filing system or remote ones accessed by http (http://domain/dir/... ).--> tats i Recerca del Departament d'Empresa i Coneixement de la Generalitat
de Catalunya 2017 through grant SGR 376.
<references title="Normative References"> </t>
<reference anchor="IPSP" target="https://www.bluetooth.org/en-us/specificat </section>
ion/adopted-specifications"> <section anchor="Contrib" numbered="false" toc="default">
<front> <name>Contributors</name>
<title>Bluetooth Internet Protocol Support Profile Specification Ver <t>
sion 1.0.0</title> <contact fullname="Carlo Alberto Boano"/> (Graz University of Technology)
<author> contributed to the design and validation of this document.
<organization>Bluetooth Special Interest Group</organization> </t>
</author> </section>
<date year="2014" month="December" day="16"/> </back>
</front>
</reference>
<reference anchor="BTCorev4.2" target="https://www.bluetooth.com/specificat
ions/archived-specifications">
<front>
<title>Bluetooth Core Specification Version 4.2</title>
<author>
<organization>Bluetooth Special Interest Group</organization>
</author>
<date year="2014" month="December" day="2"/>
</front>
</reference>
<!--?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.2
119.xml"?-->
&RFC2119;
&RFC4291;
&RFC4861;
&RFC6282;
&RFC6775;
&RFC7668;
&RFC8505;
&RFC8174;
&RFC8928;
</references>
<references title="Informative References">
<!--?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.2
119.xml"?-->
&RFC4903;
&RFC7416;
<reference anchor="BTCorev4.1" target="https://www.bluetooth.org/en-us/spec
ification/adopted-specifications">
<front>
<title>Bluetooth Core Specification Version 4.1</title>
<author>
<organization>Bluetooth Special Interest Group</organization>
</author>
<date year="2013" month="December" day="3"/>
</front>
</reference>
</references>
<!-- Change Log
v00 2011-03-07 BPa Initial version
-->
</back>
</rfc> </rfc>
 End of changes. 82 change blocks. 
628 lines changed or deleted 579 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/