6Lo Working Group C. Gomez
Internet-Draft S. Darroudi
Intended status: Standards Track UPC/i2cat
Expires: April 21, 2016 T. Savolainen
Nokia
October 19, 2015
IPv6 over BLUETOOTH(R) Low Energy Mesh Networks
draft-gomez-6lo-blemesh-00
Abstract
draft-ietf-6lo-btle describes the adaptation of 6LoWPAN techniques to
enable IPv6 over Bluetooth low energy networks that follow the star
topology. However, recent Bluetooth specifications allow the
formation of extended topologies as well. This document defines how
IPv6 is transported over Bluetooth low energy mesh networks.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on April 21, 2016.
Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
Gomez, et al. Expires April 21, 2016 [Page 1]
Internet-Draft IPv6 over Bluetooth LE mesh networks October 2015
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Terminology and Requirements Language . . . . . . . . . . 3
2. Bluetooth LE Mesh Networks . . . . . . . . . . . . . . . . . 3
3. Specification of IPv6 over Bluetooth LE mesh networks . . . . 3
3.1. Protocol stack . . . . . . . . . . . . . . . . . . . . . 3
3.2. Subnet model . . . . . . . . . . . . . . . . . . . . . . 4
3.3. Link model . . . . . . . . . . . . . . . . . . . . . . . 5
3.3.1. Stateless address autoconfiguration . . . . . . . . . 5
3.3.2. Neighbor Discovery . . . . . . . . . . . . . . . . . 5
3.3.3. Header compression . . . . . . . . . . . . . . . . . 6
3.3.4. Unicast and multicast mapping . . . . . . . . . . . . 7
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
5. Security Considerations . . . . . . . . . . . . . . . . . . . 7
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 8
7.1. Normative References . . . . . . . . . . . . . . . . . . 8
7.2. Informative References . . . . . . . . . . . . . . . . . 9
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10
1. Introduction
Bluetooth low energy (hereinafter, Bluetooth LE) was first introduced
in the Bluetooth 4.0 specification. Bluetooth LE (which has been
marketed as Bluetooth Smart) is a low-power wireless technology
designed for short-range control and monitoring applications.
Bluetooth LE is currently implemented in a wide range of consumer
electronics devices, such as smartphones and wearable devices. Given
the high potential of this technology for the Internet of Things, the
Bluetooth Special Interest Group (Bluetooth SIG) and the IETF have
produced specifications in order to enable IPv6 over Bluetooth LE,
such as the Internet Protocol Support Profile (IPSP), and draft-ietf-
6lo-btle, respectively. Bluetooth 4.0 only supports Bluetooth LE
networks that follow the star topology. In consequence, draft-ietf-
6lo-btle was specifically developed and optimized for that type of
network topology. However, subsequent Bluetooth specifications allow
the formation of extended topologies, such as the mesh topology. The
functionality described in draft-ietf-6lo-btle is not sufficient and
would fail to enable IPv6 over Bluetooth LE mesh networks. This
document specifies the mechanisms needed to enable IPv6 over
Bluetooth LE mesh networks. This specification also allows to run
IPv6 over Bluetooth LE star topology networks, albeit without all the
topology-specific optimizations contained in draft-ietf-6lo-btle.
Gomez, et al. Expires April 21, 2016 [Page 2]
Internet-Draft IPv6 over Bluetooth LE mesh networks October 2015
1.1. Terminology and Requirements Language
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 RFC 2119 [RFC2119].
The terms 6LoWPAN Node (6LN), 6LoWPAN Router (6LR) and 6LoWPAN Border
Router (6LBR) are defined as in [RFC6775], with an addition that
Bluetooth LE central and Bluetooth LE peripheral (see Section 2) can
both be adopted by a 6LN, a 6LR or a 6LBR.
2. Bluetooth LE Mesh Networks
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 traditionally been able to manage multiple
simultaneous connections with a number of devices in the peripheral
role, called peripherals hereinafter. Bluetooth 4.1 introduced the
possibility for a peripheral to be connected to more than one central
simultaneously, therefore allowing extended topologies beyond the
star topology for a Bluetooth LE network. In addition, a device may
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
discovery of IP-enabled devices and the establishment of a link layer
connection for transporting IPv6 packets. The IPSP defines the Node
and Router roles for devices that consume/originate IPv6 packets and
for devices that can route IPv6 packets, respectively. Consistently
with Bluetooth 4.1, a device may implement both roles simultaneously.
This document assumes a Bluetooth LE mesh network whereby link layer
connections have been established between neighboring IPv6-enabled
devices. In an IPv6-enabled Bluetooth LE mesh network, 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
discovery and link layer connection establishment for IPv6 packet
transport.
3. Specification of IPv6 over Bluetooth LE mesh networks
3.1. Protocol stack
Figure 1 illustrates the protocol stack for IPv6-enabled Bluetooth LE
mesh networks. There are two main differences with the IPv6 over
Bluetooth LE stack in draft-ietf-6lo-btle: a) the adaptation layer
below IPv6 (labelled as "6Lo for Bluetooth LE mesh") is now adapted
for Bluetooth LE mesh networks, and b) the protocol stack for IPv6
over Bluetooth LE mesh networks includes IPv6 routing functionality.
Gomez, et al. Expires April 21, 2016 [Page 3]
Internet-Draft IPv6 over Bluetooth LE mesh networks October 2015
+----------------------------+
| Application |
+---------+ +----------------------------+
| IPSS | | UDP/TCP/other |
+---------+ +----------------------------+
| GATT | | IPv6 |routing| |
+---------+ +----------------------------+
| ATT | | 6Lo for Bluetooth LE Mesh |
+---------+--+----------------------------+
| Bluetooth LE L2CAP |
- - +-----------------------------------------+- - - HCI
| Bluetooth LE Link Layer |
+-----------------------------------------+
| Bluetooth LE Physical |
+-----------------------------------------+
Figure 1: Protocol stack for IPv6-enabled Bluetooth LE mesh networks
3.2. Subnet model
For IPv6-based Bluetooth LE mesh networks, a multilink model has been
chosen, as further illustrated in Figure 2. As IPv6 over Bluetooth
LE is intended for constrained nodes, and for Internet of Things use
cases and environments, the complexity of implementing a separate
subnet on each peripheral-central link and routing between the
subnets appears to be excessive. In this specification, the benefits
of treating the collection of point-to-point links between a central
and its connected peripherals as a single multilink subnet rather
than a multiplicity of separate subnets are considered to outweigh
the multilink model's drawbacks as described in [RFC4903].
Gomez, et al. Expires April 21, 2016 [Page 4]
Internet-Draft IPv6 over Bluetooth LE mesh networks October 2015
/
.--------------------------------. /
/ 6LR 6LN 6LN \ /
/ \ \ \ \ /
| \ \ \ | /
| 6LN ----- 6LR --------- 6LR ------ 6LBR ----- | Internet
| <--Link--> <---Link--->/<--Link->/ | |
\ / / / \
\ 6LN ---- 6LR ----- 6LR / \
'--------------------------------' \
\
<------------ Subnet -----------------><---- IPv6 connection -->
to the Internet
Figure 2: Example of an IPv6-based Bluetooth LE mesh network
connected to the Internet
One or more 6LBRs are connected to the Internet. 6LNs are connected
to the network through a 6LR or a 6LBR. A prefix is used on the
whole subnet.
IPv6-enabled Bluetooth LE mesh networks MUST follow a route-over
approach. This document does not specify the routing protocol to be
used in an IPv6-enabled Bluetooth LE mesh network.
3.3. Link model
3.3.1. Stateless address autoconfiguration
6LN, 6LR and 6LBR IPv6 addresses of a Bluetooth LE mesh network are
configured as per section 3.2.2 of draft-ietf-6lo-btle.
Multihop DAD functionality as defined in section 8.2 of RFC 6775, or
some substitute mechanism (see section 3.3.2), MUST be supported.
3.3.2. Neighbor Discovery
'Neighbor Discovery Optimization for IPv6 over Low-Power Wireless
Personal Area Networks (6LoWPANs)' [RFC6775] describes the neighbor
discovery approach as adapted for use in several 6LoWPAN topologies,
including the mesh topology. The route-over functionality of RFC
6775 MUST be supported.
The following aspects of the Neighbor Discovery optimizations
[RFC6775] are applicable to Bluetooth LE 6LNs:
Gomez, et al. Expires April 21, 2016 [Page 5]
Internet-Draft IPv6 over Bluetooth LE mesh networks October 2015
1. A Bluetooth LE 6LN MUST NOT register its link-local address. A
Bluetooth LE 6LN MUST register its non-link-local addresses with its
routers by sending a Neighbor Solicitation (NS) message with the
Address Registration Option (ARO) and process the Neighbor
Advertisement (NA) accordingly. The NS with the ARO option MUST be
sent irrespective of the method used to generate the IID. The ARO
option requires use of an EUI-64 identifier [RFC6775]. In the case
of Bluetooth LE, the field SHALL be filled with the 48-bit device
address used by the Bluetooth LE node converted into 64-bit Modified
EUI-64 format [RFC4291].
If the 6LN registers for a same compression context multiple
addresses that are not based on Bluetooth device address, the header
compression efficiency will decrease (see the next subsection).
2. For sending Router Solicitations and processing Router
Advertisements the Bluetooth LE 6LNs MUST, respectively, follow
Sections 5.3 and 5.4 of the [RFC6775].
6LR TBD
RFC 6775 defines substitutable mechanisms for distributing prefixes
and context information (section 8.1 of RFC 6775), as well as for
Duplicate Address Detection across a route-over 6LoWPAN (section 8.2
of RFC 6775). Implementations of this specification MUST support the
features described in sections 8.1 and 8.2 of RFC 6775 unless some
alternative ("substitute") from some other specification is
supported.
3.3.3. Header compression
Header compression as defined in RFC 6282 [RFC6282], which specifies
the compression format for IPv6 datagrams on top of IEEE 802.15.4, is
REQUIRED as the basis for IPv6 header compression on top of Bluetooth
LE. All headers MUST be compressed according to RFC 6282 [RFC6282]
encoding formats.
To enable efficient header compression, when the 6LBR sends a Router
Advertisement it MUST include a 6LoWPAN Context Option (6CO)
[RFC6775] matching each address prefix advertised via a Prefix
Information Option (PIO) [RFC4861] for use in stateless address
autoconfiguration.
The specific optimizations of draft-ietf-6lo-btle for header
compression, which exploit the star topology and ARO, cannot be
generalized in a Bluetooth LE mesh network. Still, a subset of those
optimizations can be applied in some cases in a Bluetooth LE mesh
network. In particular, the latter comprise link-local interactions,
Gomez, et al. Expires April 21, 2016 [Page 6]
Internet-Draft IPv6 over Bluetooth LE mesh networks October 2015
non-link-local packet transmissions originated and performed by a
6LN, and non-link-local packet transmissions originated by a 6LN
neighbor and sent to a 6LN. For the rest of packet transmissions,
context-based compression MAY be used.
When a device transmits a packet to a neighbor, the sender MUST fully
elide 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 fully elide the destination IPv6
address if it is the link-local-address based on the neighbor's
Bluetooth device address (DAC=0, DAM=11).
When a 6LN transmits a packet, with a non-link-local source address
that the 6LN has registered with ARO in the next-hop router for the
indicated prefix, the source address MUST be fully elided if it is
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
the latest registered by the 6LN, then the 64-bits of the IID SHALL
be fully carried in-line (SAC=1, SAM=01) or if the first 48-bits of
the IID match with the latest address registered by the 6LN, then the
last 16-bits of the IID SHALL be carried in-line (SAC=1, SAM=10).
When a router transmits a packet to a neighboring 6LN, with a non-
link-local destination address, the router MUST fully elide the
destination IPv6 address if the destination address is the latest
registered by the 6LN with ARO for the indicated context (DAC=1,
DAM=11). If the destination address is a non-link-local address and
not the latest registered, then the 6LN MUST either include the IID
part fully in-line (DAM=01) or, if the first 48-bits of the IID match
to the latest registered address, then elide those 48-bits (DAM=10).
3.3.4. Unicast and multicast mapping
TBD
4. IANA Considerations
There are no IANA considerations related to this document.
5. Security Considerations
The security considerations in draft-ietf-6lo-btle apply.
Further security considerations on additional threats due to ad-hoc
routing. TBD.
Gomez, et al. Expires April 21, 2016 [Page 7]
Internet-Draft IPv6 over Bluetooth LE mesh networks October 2015
6. Acknowledgements
The Bluetooth, Bluetooth Smart and Bluetooth Smart Ready marks are
registred trademarks owned by Bluetooth SIG, Inc.
The authors of this document are grateful to all draft-ietf-6lo-btle
authors, since this document borrows many concepts (albeit, with
necessary extensions) from draft-ietf-6lo-btle.
Carles Gomez has been supported in part by the Spanish Government
Ministerio de Economia y Competitividad through project
TEC2012-32531, and FEDER.
7. References
7.1. Normative References
[BTCorev4.1]
Bluetooth Special Interest Group, "Bluetooth Core
Specification Version 4.1", December 2013,
<https://www.bluetooth.org/en-us/specification/adopted-
specifications>.
[I-D.ietf-6lo-btle]
Nieminen, J., Savolainen, T., Isomaki, M., Patil, B.,
Shelby, Z., and C. Gomez, "IPv6 over BLUETOOTH(R) Low
Energy", draft-ietf-6lo-btle-17 (work in progress), August
2015.
[IPSP] Bluetooth Special Interest Group, "Bluetooth Internet
Protocol Support Profile Specification Version 1.0.0",
December 2014, <https://www.bluetooth.org/en-
us/specification/adopted-specifications>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/
RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>.
[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing
Architecture", RFC 4291, DOI 10.17487/RFC4291, February
2006, <http://www.rfc-editor.org/info/rfc4291>.
[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
"Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,
DOI 10.17487/RFC4861, September 2007,
<http://www.rfc-editor.org/info/rfc4861>.
Gomez, et al. Expires April 21, 2016 [Page 8]
Internet-Draft IPv6 over Bluetooth LE mesh networks October 2015
[RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless
Address Autoconfiguration", RFC 4862, DOI 10.17487/
RFC4862, September 2007,
<http://www.rfc-editor.org/info/rfc4862>.
[RFC6282] Hui, J., Ed. and P. Thubert, "Compression Format for IPv6
Datagrams over IEEE 802.15.4-Based Networks", RFC 6282,
DOI 10.17487/RFC6282, September 2011,
<http://www.rfc-editor.org/info/rfc6282>.
[RFC6775] Shelby, Z., Ed., Chakrabarti, S., Nordmark, E., and C.
Bormann, "Neighbor Discovery Optimization for IPv6 over
Low-Power Wireless Personal Area Networks (6LoWPANs)", RFC
6775, DOI 10.17487/RFC6775, November 2012,
<http://www.rfc-editor.org/info/rfc6775>.
[RFC7136] Carpenter, B. and S. Jiang, "Significance of IPv6
Interface Identifiers", RFC 7136, DOI 10.17487/RFC7136,
February 2014, <http://www.rfc-editor.org/info/rfc7136>.
7.2. Informative References
[fifteendotfour]
IEEE Computer Society, "IEEE Std. 802.15.4-2011 IEEE
Standard for Local and metropolitan area networks--Part
15.4: Low-Rate Wireless Personal Area Networks (LR-
WPANs)", June 2011.
[I-D.ietf-6man-default-iids]
Gont, F., Cooper, A., Thaler, D., and S. LIU,
"Recommendation on Stable IPv6 Interface Identifiers",
draft-ietf-6man-default-iids-08 (work in progress),
October 2015.
[IEEE802-2001]
Institute of Electrical and Electronics Engineers (IEEE),
"IEEE 802-2001 Standard for Local and Metropolitan Area
Networks: Overview and Architecture", 2002.
[RFC3315] Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins,
C., and M. Carney, "Dynamic Host Configuration Protocol
for IPv6 (DHCPv6)", RFC 3315, DOI 10.17487/RFC3315, July
2003, <http://www.rfc-editor.org/info/rfc3315>.
[RFC3610] Whiting, D., Housley, R., and N. Ferguson, "Counter with
CBC-MAC (CCM)", RFC 3610, DOI 10.17487/RFC3610, September
2003, <http://www.rfc-editor.org/info/rfc3610>.
Gomez, et al. Expires April 21, 2016 [Page 9]
Internet-Draft IPv6 over Bluetooth LE mesh networks October 2015
[RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic
Host Configuration Protocol (DHCP) version 6", RFC 3633,
DOI 10.17487/RFC3633, December 2003,
<http://www.rfc-editor.org/info/rfc3633>.
[RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)",
RFC 3972, DOI 10.17487/RFC3972, March 2005,
<http://www.rfc-editor.org/info/rfc3972>.
[RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast
Addresses", RFC 4193, DOI 10.17487/RFC4193, October 2005,
<http://www.rfc-editor.org/info/rfc4193>.
[RFC4903] Thaler, D., "Multi-Link Subnet Issues", RFC 4903, DOI
10.17487/RFC4903, June 2007,
<http://www.rfc-editor.org/info/rfc4903>.
[RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy
Extensions for Stateless Address Autoconfiguration in
IPv6", RFC 4941, DOI 10.17487/RFC4941, September 2007,
<http://www.rfc-editor.org/info/rfc4941>.
[RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler,
"Transmission of IPv6 Packets over IEEE 802.15.4
Networks", RFC 4944, DOI 10.17487/RFC4944, September 2007,
<http://www.rfc-editor.org/info/rfc4944>.
[RFC5535] Bagnulo, M., "Hash-Based Addresses (HBA)", RFC 5535, DOI
10.17487/RFC5535, June 2009,
<http://www.rfc-editor.org/info/rfc5535>.
[RFC7217] Gont, F., "A Method for Generating Semantically Opaque
Interface Identifiers with IPv6 Stateless Address
Autoconfiguration (SLAAC)", RFC 7217, DOI 10.17487/
RFC7217, April 2014,
<http://www.rfc-editor.org/info/rfc7217>.
Authors' Addresses
Carles Gomez
Universitat Politecnica de Catalunya/Fundacio i2cat
C/Esteve Terradas, 7
Castelldefels 08860
Spain
Email: carlesgo@entel.upc.edu
Gomez, et al. Expires April 21, 2016 [Page 10]
Internet-Draft IPv6 over Bluetooth LE mesh networks October 2015
Seyed Mahdi Darroudi
Universitat Politecnica de Catalunya/Fundacio i2cat
C/Esteve Terradas, 7
Castelldefels 08860
Spain
Email: s.darroudi2014@yahoo.com
Teemu Savolainen
Nokia
Visiokatu 3
Tampere 33720
Finland
Email: teemu.savolainen@nokia.com
Gomez, et al. Expires April 21, 2016 [Page 11]