draft-ietf-6lo-blemesh-02.txt   draft-ietf-6lo-blemesh-03.txt 
6Lo Working Group C. Gomez 6Lo Working Group C. Gomez
Internet-Draft S. Darroudi Internet-Draft S. Darroudi
Intended status: Standards Track UPC/i2cat Intended status: Standards Track Universitat Politecnica de Catalunya
Expires: March 14, 2018 T. Savolainen Expires: January 3, 2019 T. Savolainen
Nokia DarkMatter
September 10, 2017 M. Spoerk
Graz University of Technology
July 2, 2018
IPv6 Mesh over BLUETOOTH(R) Low Energy using IPSP IPv6 Mesh over BLUETOOTH(R) Low Energy using IPSP
draft-ietf-6lo-blemesh-02 draft-ietf-6lo-blemesh-03
Abstract Abstract
RFC 7668 describes the adaptation of 6LoWPAN techniques to enable RFC 7668 describes the adaptation of 6LoWPAN techniques to enable
IPv6 over Bluetooth low energy networks that follow the star IPv6 over Bluetooth low energy networks that follow the star
topology. However, recent Bluetooth specifications allow the topology. However, recent Bluetooth specifications allow the
formation of extended topologies as well. This document specifies formation of extended topologies as well. This document specifies
the mechanisms needed to enable IPv6 over mesh networks composed of the mechanisms needed to enable IPv6 over mesh networks composed of
Bluetooth low energy links established by using the Bluetooth Bluetooth low energy links established by using the Bluetooth
Internet Protocol Support Profile. Internet Protocol Support Profile.
skipping to change at page 1, line 38 skipping to change at page 1, line 40
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on March 14, 2018. This Internet-Draft will expire on January 3, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the Copyright (c) 2018 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Terminology and Requirements Language . . . . . . . . . . 3 1.1. Terminology and Requirements Language . . . . . . . . . . 3
2. Bluetooth LE Networks and the IPSP . . . . . . . . . . . . . 3 2. Bluetooth LE Networks and the IPSP . . . . . . . . . . . . . 3
3. Specification of IPv6 mesh over Bluetooth LE networks . . . . 3 3. Specification of IPv6 mesh over Bluetooth LE networks . . . . 4
3.1. Protocol stack . . . . . . . . . . . . . . . . . . . . . 4 3.1. Protocol stack . . . . . . . . . . . . . . . . . . . . . 4
3.2. Subnet model . . . . . . . . . . . . . . . . . . . . . . 4 3.2. Subnet model . . . . . . . . . . . . . . . . . . . . . . 4
3.3. Link model . . . . . . . . . . . . . . . . . . . . . . . 5 3.3. Link model . . . . . . . . . . . . . . . . . . . . . . . 5
3.3.1. Stateless address autoconfiguration . . . . . . . . . 5 3.3.1. Stateless address autoconfiguration . . . . . . . . . 5
3.3.2. Neighbor Discovery . . . . . . . . . . . . . . . . . 5 3.3.2. Neighbor Discovery . . . . . . . . . . . . . . . . . 5
3.3.3. Header compression . . . . . . . . . . . . . . . . . 6 3.3.3. Header compression . . . . . . . . . . . . . . . . . 7
3.3.4. Unicast and multicast mapping . . . . . . . . . . . . 7 3.3.4. Unicast and multicast mapping . . . . . . . . . . . . 8
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
5. Security Considerations . . . . . . . . . . . . . . . . . . . 8 5. Security Considerations . . . . . . . . . . . . . . . . . . . 8
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 6. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 8
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9
7.1. Normative References . . . . . . . . . . . . . . . . . . 9 8. Appendix . . . . . . . . . . . . . . . . . . . . . . . . . . 9
7.2. Informative References . . . . . . . . . . . . . . . . . 9 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 12
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 9.1. Normative References . . . . . . . . . . . . . . . . . . 12
9.2. Informative References . . . . . . . . . . . . . . . . . 13
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13
1. Introduction 1. Introduction
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
skipping to change at page 3, line 38 skipping to change at page 3, line 42
star topology for a Bluetooth LE network. In addition, a device may star topology for a Bluetooth LE network. In addition, a device may
simultaneously be a central in a set of link layer connections, as simultaneously be a central in a set of link layer connections, as
well as a peripheral in others. On the other hand, the IPSP enables well as a peripheral in others. On the other hand, the IPSP enables
discovery of IP-enabled devices and the establishment of a link layer discovery of IP-enabled devices and the establishment of a link layer
connection for transporting IPv6 packets. The IPSP defines the Node connection for transporting IPv6 packets. The IPSP defines the Node
and Router roles for devices that consume/originate IPv6 packets and and Router roles for devices that consume/originate IPv6 packets and
for devices that can route IPv6 packets, respectively. Consistently for devices that can route IPv6 packets, respectively. Consistently
with Bluetooth 4.1, a device may implement both roles simultaneously. with Bluetooth 4.1, a device may implement both roles simultaneously.
This document assumes a mesh network composed of Bluetooth LE links, This document assumes a mesh network composed of Bluetooth LE links,
where link layer connections have been established between where link layer connections are established between neighboring
neighboring IPv6-enabled devices. The IPv6 forwarding devices of the IPv6-enabled devices (see Section 3.3.2, item 3.b)). The IPv6
mesh have to implement both Node and Router roles, while simpler forwarding devices of the mesh have to implement both Node and Router
leaf-only nodes can implement only the Node role. In an IPv6-enabled roles, while simpler leaf-only nodes can implement only the Node
mesh of Bluetooth LE links, a node is a neighbor of another node, and role. In an IPv6-enabled mesh of Bluetooth LE links, a node is a
vice versa, if a link layer connection has been established between neighbor of another node, and vice versa, if a link layer connection
both by using the IPSP functionality for discovery and link layer has been established between both by using the IPSP functionality for
connection establishment for IPv6 packet transport. discovery and link layer connection establishment for IPv6 packet
transport.
3. Specification of IPv6 mesh over Bluetooth LE networks 3. Specification of IPv6 mesh over Bluetooth LE networks
3.1. Protocol stack 3.1. Protocol stack
Figure 1 illustrates the protocol stack for IPv6 mesh over Bluetooth Figure 1 illustrates the protocol stack for IPv6 mesh over Bluetooth
LE networks. There are two main differences with the IPv6 over LE networks. There are two main differences with the IPv6 over
Bluetooth LE stack in RFC 7668: a) the adaptation layer below IPv6 Bluetooth LE stack in RFC 7668: a) the adaptation layer below IPv6
(labelled as "6Lo for IPv6 mesh of Bluetooth LE") is now adapted for (labelled as "6Lo for IPv6 mesh of Bluetooth LE") is now adapted for
mesh networks of Bluetooth LE links, and b) the protocol stack for mesh networks of Bluetooth LE links, and b) the protocol stack for
IPv6 mesh networks of Bluetooth LE links includes IPv6 routing IPv6 mesh networks of Bluetooth LE links includes IPv6 routing
functionality. functionality.
skipping to change at page 6, line 25 skipping to change at page 6, line 25
If the 6LN registers for a same compression context multiple If the 6LN registers for a same compression context multiple
addresses that are not based on Bluetooth device address, the header addresses that are not based on Bluetooth device address, the header
compression efficiency will decrease. compression efficiency will decrease.
2. For sending Router Solicitations and processing Router 2. For sending Router Solicitations and processing Router
Advertisements the Bluetooth LE hosts MUST, respectively, follow Advertisements the Bluetooth LE hosts MUST, respectively, follow
Sections 5.3 and 5.4 of the [RFC6775]. Sections 5.3 and 5.4 of the [RFC6775].
3. The router behavior for 6LRs and 6LBRs is described in Section 6 3. The router behavior for 6LRs and 6LBRs is described in Section 6
of RFC 6775. However, as per this specification, routers SHALL NOT of RFC 6775. However, as per this specification: a) Routers SHALL
use multicast NSs to discover other routers' link layer addresses. NOT use multicast NSs to discover other routers' link layer
addresses. b) As per section 6.2 of RFC 6775, in a dynamic
configuration scenario, a 6LR comes up as a non-router and waits to
receive a Router Advertisement for configuring its own interface
address first, before setting its interfaces to be advertising
interfaces and turning into a router. In order to support such
operation in an IPv6-enabled mesh of Bluetooth LE links, a 6LR first
uses the IPSP Node role only. Once the 6LR has established a
connection with another node previously running as a router, and
receives a Router Advertisement from that router, the 6LR configures
its own interface address, it turns into a router, and it runs as an
IPSP Router. A 6LBR uses the IPSP Router role since the 6LBR is
initialized. See an example in the Appendix.
4. Border router behavior is described in Section 7 of RFC 6775. 4. Border router behavior is described in Section 7 of RFC 6775.
RFC 6775 defines substitutable mechanisms for distributing prefixes RFC 6775 defines substitutable mechanisms for distributing prefixes
and context information (section 8.1 of RFC 6775), as well as for and context information (section 8.1 of RFC 6775), as well as for
Duplicate Address Detection across a route-over 6LoWPAN (section 8.2 Duplicate Address Detection across a route-over 6LoWPAN (section 8.2
of RFC 6775). Implementations of this specification MUST support the of RFC 6775). Implementations of this specification MUST support the
features described in sections 8.1 and 8.2 of RFC 6775 unless some features described in sections 8.1 and 8.2 of RFC 6775 unless some
alternative ("substitute") from some other specification is alternative ("substitute") from some other specification is
supported. supported.
skipping to change at page 8, line 32 skipping to change at page 8, line 46
threats due to failure to keep routing information, threats and threats due to failure to keep routing information, threats and
attacks on integrity, and threats and attacks on availability. attacks on integrity, and threats and attacks on availability.
Reported countermeasures comprise confidentiality attack, integrity Reported countermeasures comprise confidentiality attack, integrity
attack, and availability attack countermeasures. attack, and availability attack countermeasures.
While this specification does not state the routing protocol to be While this specification does not state the routing protocol to be
used in IPv6 mesh over Bluetooth LE networks, the guidance of RFC used in IPv6 mesh over Bluetooth LE networks, the guidance of RFC
7416 is useful when RPL is used in such scenarios. Furthermore, such 7416 is useful when RPL is used in such scenarios. Furthermore, such
guidance may partly apply for other routing protocols as well. guidance may partly apply for other routing protocols as well.
6. Acknowledgements 6. Contributors
Carlo Alberto Boano (Graz University of Technology) contributed to
the design and validation of this document.
7. Acknowledgements
The Bluetooth, Bluetooth Smart and Bluetooth Smart Ready marks are The Bluetooth, Bluetooth Smart and Bluetooth Smart Ready marks are
registered trademarks owned by Bluetooth SIG, Inc. registered trademarks owned by Bluetooth SIG, Inc.
The authors of this document are grateful to all RFC 7668 authors, The authors of this document are grateful to all RFC 7668 authors,
since this document borrows many concepts (albeit, with necessary since this document borrows many concepts (albeit, with necessary
extensions) from RFC 7668. extensions) from RFC 7668.
The authors also thank Alain Michaud, Mark Powell and Martin Turon The authors also thank Alain Michaud, Mark Powell and Martin Turon
for their comments, which helped improve the document. for their comments, which helped improve the document.
Carles Gomez has been supported in part by the Spanish Government Carles Gomez has been supported in part by the Spanish Government
Ministerio de Economia y Competitividad through project Ministerio de Economia y Competitividad through project
TEC2012-32531, and FEDER. TEC2012-32531, and FEDER.
7. References 8. Appendix
7.1. Normative References
This appendix provides an example of Bluetooth LE connection
establishment and use of IPSP roles in an IPv6-enabled mesh of
Bluetooth LE links that uses dynamic configuration. The example
follows text in Section 3.3.2, item 3.b).
The example assumes a network with one 6LBR, two 6LRs and three 6LNs,
as shown in Figure 3. Connectivity between the 6LNs and the 6LBR is
only possible via the 6LRs.
The following text describes the different steps as time evolves, in
the example. Note that other sequences of events that may lead to
the same final scenario are also possible.
At the beginning, the 6LBR starts running as an IPSP Router, whereas
the rest of devices are not yet initialized (Step 1). Next, the 6LRs
start running as IPSP Nodes, i.e., they use Bluetooth LE
advertisement packets to announce their presence and support of IPv6
capabilities (Step 2). The 6LBR (already running as an IPSP Router)
discovers the presence of the 6LRs and establishes one Bluetooth LE
connection with each 6LR (Step 3). After establishment of those link
layer connections (and after reception of Router Advertisements from
the 6LBR), Step 4, the 6LRs start operating as routers, and also
initiate the IPSP Router role (note: whether the IPSP Node role is
kept running simultaneously is an implementation decision). Then,
6LNs start running the IPSP Node role (Step 5). Finally, the 6LRs
discover presence of the 6LNs and establish connections with the
latter (Step 6).
Step 1
******
6LBR
(IPSP: Router)
6LR 6LR
(not initialized) (not initialized)
6LN 6LN 6LN
(not initialized) (not initialized) (not initialized)
Step 2
******
6LBR
(IPSP: Router)
6LR 6LR
(IPSP: Node) (IPSP: Node)
6LN 6LN 6LN
(not initialized) (not initialized) (not initialized)
Step 3
******
6LBR
(IPSP: Router)
Bluetooth LE connection --> / \
/ \
6LR 6LR
(IPSP: Node) (IPSP: Node)
6LN 6LN 6LN
(not initialized) (not initialized) (not initialized)
Step 4
******
6LBR
(IPSP: Router)
/ \
/ \
6LR 6LR
(IPSP: Router) (IPSP: Router)
6LN 6LN 6LN
(not initialized) (not initialized) (not initialized)
Step 5
******
6LBR
(IPSP: Router)
/ \
/ \
6LR 6LR
(IPSP: Router) (IPSP: Router)
6LN 6LN 6LN
(IPSP: Node) (IPSP: Node) (IPSP: Node)
Step 6
******
6LBR
(IPSP: Router)
/ \
/ \
6LR 6LR
(IPSP: Router) (IPSP: Router)
/ \ / \
/ \ / \
/ \ / \
6LN 6LN 6LN
(IPSP: Node) (IPSP: Node) (IPSP: Node)
Figure 3: An example of connection establishment and use of IPSP
roles in an IPv6-enabled mesh of Bluetooth LE links.
9. References
9.1. Normative References
[BTCorev4.1] [BTCorev4.1]
Bluetooth Special Interest Group, "Bluetooth Core Bluetooth Special Interest Group, "Bluetooth Core
Specification Version 4.1", December 2013, Specification Version 4.1", December 2013,
<https://www.bluetooth.org/en-us/specification/ <https://www.bluetooth.org/en-us/specification/
adopted-specifications>. adopted-specifications>.
[IPSP] Bluetooth Special Interest Group, "Bluetooth Internet [IPSP] Bluetooth Special Interest Group, "Bluetooth Internet
Protocol Support Profile Specification Version 1.0.0", Protocol Support Profile Specification Version 1.0.0",
December 2014, <https://www.bluetooth.org/en- December 2014, <https://www.bluetooth.org/en-
skipping to change at page 9, line 47 skipping to change at page 13, line 5
Bormann, "Neighbor Discovery Optimization for IPv6 over Bormann, "Neighbor Discovery Optimization for IPv6 over
Low-Power Wireless Personal Area Networks (6LoWPANs)", Low-Power Wireless Personal Area Networks (6LoWPANs)",
RFC 6775, DOI 10.17487/RFC6775, November 2012, RFC 6775, DOI 10.17487/RFC6775, November 2012,
<https://www.rfc-editor.org/info/rfc6775>. <https://www.rfc-editor.org/info/rfc6775>.
[RFC7668] Nieminen, J., Savolainen, T., Isomaki, M., Patil, B., [RFC7668] Nieminen, J., Savolainen, T., Isomaki, M., Patil, B.,
Shelby, Z., and C. Gomez, "IPv6 over BLUETOOTH(R) Low Shelby, Z., and C. Gomez, "IPv6 over BLUETOOTH(R) Low
Energy", RFC 7668, DOI 10.17487/RFC7668, October 2015, Energy", RFC 7668, DOI 10.17487/RFC7668, October 2015,
<https://www.rfc-editor.org/info/rfc7668>. <https://www.rfc-editor.org/info/rfc7668>.
7.2. Informative References 9.2. Informative References
[RFC4903] Thaler, D., "Multi-Link Subnet Issues", RFC 4903, [RFC4903] Thaler, D., "Multi-Link Subnet Issues", RFC 4903,
DOI 10.17487/RFC4903, June 2007, DOI 10.17487/RFC4903, June 2007,
<https://www.rfc-editor.org/info/rfc4903>. <https://www.rfc-editor.org/info/rfc4903>.
[RFC7416] Tsao, T., Alexander, R., Dohler, M., Daza, V., Lozano, A., [RFC7416] Tsao, T., Alexander, R., Dohler, M., Daza, V., Lozano, A.,
and M. Richardson, Ed., "A Security Threat Analysis for and M. Richardson, Ed., "A Security Threat Analysis for
the Routing Protocol for Low-Power and Lossy Networks the Routing Protocol for Low-Power and Lossy Networks
(RPLs)", RFC 7416, DOI 10.17487/RFC7416, January 2015, (RPLs)", RFC 7416, DOI 10.17487/RFC7416, January 2015,
<https://www.rfc-editor.org/info/rfc7416>. <https://www.rfc-editor.org/info/rfc7416>.
Authors' Addresses Authors' Addresses
Carles Gomez Carles Gomez
Universitat Politecnica de Catalunya/Fundacio i2cat Universitat Politecnica de Catalunya
C/Esteve Terradas, 7 C/Esteve Terradas, 7
Castelldefels 08860 Castelldefels 08860
Spain Spain
Email: carlesgo@entel.upc.edu Email: carlesgo@entel.upc.edu
Seyed Mahdi Darroudi Seyed Mahdi Darroudi
Universitat Politecnica de Catalunya/Fundacio i2cat Universitat Politecnica de Catalunya
C/Esteve Terradas, 7 C/Esteve Terradas, 7
Castelldefels 08860 Castelldefels 08860
Spain Spain
Email: sm.darroudi@entel.upc.edu Email: sm.darroudi@entel.upc.edu
Teemu Savolainen Teemu Savolainen
Nokia Technologies DarkMatter LLC
Hatanpaan valtatie 30
Tampere 33100
Finland
Email: teemu.savolainen@nokia.com Email: teemu.savolainen@darkmatter.ae
Michael Spoerk
Graz University of Technology
Inffeldgasse 16/I
Graz 8010
Austria
Email: michael.spoerk@tugraz.at
 End of changes. 17 change blocks. 
35 lines changed or deleted 165 lines changed or added

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