draft-ietf-6lo-blemesh-05.txt   draft-ietf-6lo-blemesh-06.txt 
6Lo Working Group C. Gomez 6Lo Working Group C. Gomez
Internet-Draft S. Darroudi Internet-Draft S. Darroudi
Intended status: Standards Track Universitat Politecnica de Catalunya Intended status: Standards Track Universitat Politecnica de Catalunya
Expires: September 10, 2019 T. Savolainen Expires: March 31, 2020 T. Savolainen
DarkMatter DarkMatter
M. Spoerk M. Spoerk
Graz University of Technology Graz University of Technology
March 9, 2019 September 28, 2019
IPv6 Mesh over BLUETOOTH(R) Low Energy using IPSP IPv6 Mesh over BLUETOOTH(R) Low Energy using IPSP
draft-ietf-6lo-blemesh-05 draft-ietf-6lo-blemesh-06
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
mechanisms that are needed to enable IPv6 mesh over Bluetooth Low mechanisms that are needed to enable IPv6 mesh over Bluetooth Low
Energy links established by using the Bluetooth Internet Protocol Energy links established by using the Bluetooth Internet Protocol
Support Profile. This document does not specify the routing protocol Support Profile. This document does not specify the routing protocol
skipping to change at page 1, line 41 skipping to change at page 1, line 41
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 September 10, 2019. This Internet-Draft will expire on March 31, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2019 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
skipping to change at page 2, line 29 skipping to change at page 2, line 29
3.2. Subnet model . . . . . . . . . . . . . . . . . . . . . . 5 3.2. Subnet model . . . . . . . . . . . . . . . . . . . . . . 5
3.3. Link model . . . . . . . . . . . . . . . . . . . . . . . 6 3.3. Link model . . . . . . . . . . . . . . . . . . . . . . . 6
3.3.1. Stateless address autoconfiguration . . . . . . . . . 6 3.3.1. Stateless address autoconfiguration . . . . . . . . . 6
3.3.2. Neighbor Discovery . . . . . . . . . . . . . . . . . 6 3.3.2. Neighbor Discovery . . . . . . . . . . . . . . . . . 6
3.3.3. Header compression . . . . . . . . . . . . . . . . . 7 3.3.3. Header compression . . . . . . . . . . . . . . . . . 7
3.3.4. Unicast and multicast mapping . . . . . . . . . . . . 8 3.3.4. Unicast and multicast mapping . . . . . . . . . . . . 8
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
5. Security Considerations . . . . . . . . . . . . . . . . . . . 9 5. Security Considerations . . . . . . . . . . . . . . . . . . . 9
6. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 9 6. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 9
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9
8. Appendix . . . . . . . . . . . . . . . . . . . . . . . . . . 10 8. Appendix A: Bluetooth LE connection establishment example . . 10
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 9. Appendix B: Node joining procedure . . . . . . . . . . . . . 13
9.1. Normative References . . . . . . . . . . . . . . . . . . 13 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 13
9.2. Informative References . . . . . . . . . . . . . . . . . 14 10.1. Normative References . . . . . . . . . . . . . . . . . . 13
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 10.2. Informative References . . . . . . . . . . . . . . . . . 14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15
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 7, line 42 skipping to change at page 7, line 42
3.3.3. Header compression 3.3.3. Header compression
Header compression as defined in RFC 6282 [RFC6282], which specifies Header compression as defined in RFC 6282 [RFC6282], which specifies
the compression format for IPv6 datagrams on top of IEEE 802.15.4, is the compression format for IPv6 datagrams on top of IEEE 802.15.4, is
REQUIRED as the basis for IPv6 header compression on top of Bluetooth REQUIRED as the basis for IPv6 header compression on top of Bluetooth
LE. All headers MUST be compressed according to RFC 6282 [RFC6282] LE. All headers MUST be compressed according to RFC 6282 [RFC6282]
encoding formats. encoding formats.
To enable efficient header compression, when the 6LBR sends a Router To enable efficient header compression, when the 6LBR sends a Router
Advertisement it MUST include a 6LoWPAN Context Option (6CO) Advertisement it MAY include a 6LoWPAN Context Option (6CO) [RFC6775]
[RFC6775] matching each address prefix advertised via a Prefix matching each address prefix advertised via a Prefix Information
Information Option (PIO) [RFC4861] for use in stateless address Option (PIO) [RFC4861] for use in stateless address
autoconfiguration. autoconfiguration. Note that 6CO is not needed for context-based
compression when a single prefix is used in the network.
The specific optimizations of RFC 7668 for header compression, which The specific optimizations of RFC 7668 for header compression, which
exploit the star topology and ARO, cannot be generalized in an IPv6 exploited the star topology and ARO (note that the latter has been
updated by EARO as per RFC 8505), 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. In particular, the can be applied in some cases in such a network. These cases comprise
latter comprise link-local interactions, non-link- local packet link-local interactions, non-link-local packet transmissions
transmissions originated and performed by a 6LN, and non-link-local originated and performed by a 6LN, and non-link-local packets
packets transmitted (but not necessarily originated) by the neighbor intended for a 6LN that are originated or forwarded by a neighbor of
of a 6LN to that 6LN. For the rest of packet transmissions, context- that 6LN. For the rest of packet transmissions, context- based
based compression MAY be used. compression MAY be used.
When a device transmits a packet to a neighbor, the sender MUST fully 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 elide the source IID if the source IPv6 address is the link-local
address based on the sender's Bluetooth device address (SAC=0, address based on the sender's Bluetooth device address (SAC=0,
SAM=11). The sender also MUST fully elide the destination IPv6 SAM=11). The sender also MUST fully elide the destination IPv6
address if it is the link-local address based on the neighbor's address if it is the link-local address based on the neighbor's
Bluetooth device address (DAC=0, DAM=11). Bluetooth device address (DAC=0, DAM=11).
A 6LN SHOULD register its non-link-local address with ARO in the A 6LN SHOULD register its non-link-local address with EARO in the
next-hop router. Note that in some cases (e.g. very short-lived next-hop router. Note that in some cases (e.g. very short-lived
connections) it may not be worthwhile for a 6LN to send an NS with connections) it may not be worthwhile for a 6LN to send an NS with
ARO for registering its address. When a 6LN transmits a packet, with EARO for registering its address. When a 6LN transmits a packet,
a non-link-local source address that the 6LN has registered with ARO with a non-link-local source address that the 6LN has registered with
in the next-hop router for the indicated prefix, the source address EARO in the next-hop router for the indicated prefix, the source
MUST be fully elided if it is the latest address that the 6LN has address MUST be fully elided if it is the latest address that the 6LN
registered for the indicated prefix (SAC=1, SAM=11). If the source has registered for the indicated prefix (SAC=1, SAM=11). If the
non-link-local address is not the latest registered by the 6LN, then source non-link-local address is not the latest registered by the
the 64 bits of the IID SHALL be fully carried in-line (SAC=1, SAM=01) 6LN, then the 64 bits of the IID SHALL be fully carried in-line
or if the first 48 bits of the IID match with the latest address (SAC=1, SAM=01) or if the first 48 bits of the IID match with the
registered by the 6LN, then the last 16 bits of the IID SHALL be latest address registered by the 6LN, then the last 16 bits of the
carried in-line (SAC=1, SAM=10). IID SHALL be carried in-line (SAC=1, SAM=10).
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-local destination address, the router MUST fully elide the link-local destination address, the router MUST 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 ARO 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, then the 6LN MUST either include the IID 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 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). to the latest registered address, then elide those 48 bits (DAM=10).
3.3.4. Unicast and multicast mapping 3.3.4. Unicast and multicast mapping
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 If a node needs to send a multicast packet to several neighbors, it
skipping to change at page 10, line 13 skipping to change at page 10, line 13
extensions) from RFC 7668. extensions) from RFC 7668.
The authors also thank Alain Michaud, Mark Powell, Martin Turon, The authors also thank Alain Michaud, Mark Powell, Martin Turon,
Bilhanan Silverajan, Rahul Jadhav and Pascal Thubert for their Bilhanan Silverajan, Rahul Jadhav and Pascal Thubert for their
comments, which helped improve the document. 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 projects Ministerio de Economia y Competitividad through projects
TEC2012-32531, TEC2016-79988-P and FEDER. TEC2012-32531, TEC2016-79988-P and FEDER.
8. Appendix 8. Appendix A: Bluetooth LE connection establishment example
This appendix provides an example of Bluetooth LE connection This appendix provides an example of Bluetooth LE connection
establishment and use of IPSP roles in an IPv6 mesh over Bluetooth LE establishment and use of IPSP roles in an IPv6 mesh over Bluetooth LE
links that uses dynamic configuration. The example follows text in links that uses dynamic configuration. The example follows text in
Section 3.3.2, item 3.b). Section 3.3.2, item 3.b).
The example assumes a network with one 6LBR, two 6LRs and three 6LNs, 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 as shown in Figure 3. Connectivity between the 6LNs and the 6LBR is
only possible via the 6LRs. only possible via the 6LRs.
skipping to change at page 13, line 5 skipping to change at page 13, line 5
(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)
Figure 3: An example of connection establishment and use of IPSP Figure 3: An example of connection establishment and use of IPSP
roles in an IPv6 mesh over Bluetooth LE links. roles in an IPv6 mesh over Bluetooth LE links.
9. References 9. Appendix B: Node joining procedure
9.1. Normative References This appendix provides a diagram that illustrates the node joining
procedure. First of all, the joining node advertises its presence in
order to allow establishing Bluetooth LE connections with neighbors
that already belong to a network. The latter typically run as a 6LR
or as a 6LBR. After Bluetooth LE connection establishment, the
joining node starts acting as a 6LN.
Figure 4 shows the sequence of messages that are exchanged by the 6LN
and a neighboring 6LR that already belongs to the network, after the
establishment of a Bluetooth LE connection between both devices.
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-local prefix in use in the network, the 6LN creates its non-
link-local address, registers that address with EARO (3) in the 6LR,
and multihop DAD is performed (4). The next step is the transmission
of the NA message sent by the 6LR in response 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.
(1) 6LN ----(RS)-------> 6LR
(2) 6LN <---(RA-PIO)---- 6LR
(3) 6LN ----(NS-EARO)--> 6LR
(4) [Multihop DAD procedure]
(5) 6LN <---(NA)-------- 6LR
Figure 4: Message exchange diagram for a joining node
10. References
10.1. Normative References
[BTCorev4.2] [BTCorev4.2]
Bluetooth Special Interest Group, "Bluetooth Core Bluetooth Special Interest Group, "Bluetooth Core
Specification Version 4.2", December 2014, Specification Version 4.2", December 2014,
<https://www.bluetooth.com/specifications/ <https://www.bluetooth.com/specifications/archived-
archived-specifications>. 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-
us/specification/adopted-specifications>. us/specification/adopted-specifications>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
skipping to change at page 14, line 11 skipping to change at page 14, line 41
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>.
[RFC8505] Thubert, P., Ed., Nordmark, E., Chakrabarti, S., and C. [RFC8505] Thubert, P., Ed., Nordmark, E., Chakrabarti, S., and C.
Perkins, "Registration Extensions for IPv6 over Low-Power Perkins, "Registration Extensions for IPv6 over Low-Power
Wireless Personal Area Network (6LoWPAN) Neighbor Wireless Personal Area Network (6LoWPAN) Neighbor
Discovery", RFC 8505, DOI 10.17487/RFC8505, November 2018, Discovery", RFC 8505, DOI 10.17487/RFC8505, November 2018,
<https://www.rfc-editor.org/info/rfc8505>. <https://www.rfc-editor.org/info/rfc8505>.
9.2. Informative References 10.2. Informative 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-
adopted-specifications>. specifications>.
[I-D.ietf-6lo-ap-nd] [I-D.ietf-6lo-ap-nd]
Thubert, P., Sarikaya, B., Sethi, M., and R. Struik, Thubert, P., Sarikaya, B., Sethi, M., and R. Struik,
"Address Protected Neighbor Discovery for Low-power and "Address Protected Neighbor Discovery for Low-power and
Lossy Networks", draft-ietf-6lo-ap-nd-11 (work in Lossy Networks", draft-ietf-6lo-ap-nd-12 (work in
progress), February 2019. progress), April 2019.
[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>.
 End of changes. 18 change blocks. 
42 lines changed or deleted 75 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/