draft-ietf-6lo-blemesh-04.txt   draft-ietf-6lo-blemesh-05.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: July 20, 2019 T. Savolainen Expires: September 10, 2019 T. Savolainen
DarkMatter DarkMatter
M. Spoerk M. Spoerk
Graz University of Technology Graz University of Technology
January 16, 2019 March 9, 2019
IPv6 Mesh over BLUETOOTH(R) Low Energy using IPSP IPv6 Mesh over BLUETOOTH(R) Low Energy using IPSP
draft-ietf-6lo-blemesh-04 draft-ietf-6lo-blemesh-05
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 mechanisms that are needed to enable IPv6 mesh over Bluetooth Low
Bluetooth low energy links established by using the Bluetooth Energy links established by using the Bluetooth Internet Protocol
Internet Protocol Support Profile. Support Profile. This document does not specify the routing protocol
to be used in an IPv6 mesh over Bluetooth LE links.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
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 July 20, 2019. This Internet-Draft will expire on September 10, 2019.
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 16 skipping to change at page 2, line 17
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 . . . . 4 3. Specification of IPv6 mesh over Bluetooth LE links . . . . . 4
3.1. Protocol stack . . . . . . . . . . . . . . . . . . . . . 4 3.1. Protocol stack . . . . . . . . . . . . . . . . . . . . . 4
3.2. Subnet model . . . . . . . . . . . . . . . . . . . . . . 4 3.2. Subnet model . . . . . . . . . . . . . . . . . . . . . . 5
3.3. Link model . . . . . . . . . . . . . . . . . . . . . . . 5 3.3. Link model . . . . . . . . . . . . . . . . . . . . . . . 6
3.3.1. Stateless address autoconfiguration . . . . . . . . . 5 3.3.1. Stateless address autoconfiguration . . . . . . . . . 6
3.3.2. Neighbor Discovery . . . . . . . . . . . . . . . . . 5 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 . . . . . . . . . . . . . . . . . . . . . 8 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
5. Security Considerations . . . . . . . . . . . . . . . . . . . 8 5. Security Considerations . . . . . . . . . . . . . . . . . . . 9
6. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 8 6. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 9
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9
8. Appendix . . . . . . . . . . . . . . . . . . . . . . . . . . 9 8. Appendix . . . . . . . . . . . . . . . . . . . . . . . . . . 10
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 13
9.1. Normative References . . . . . . . . . . . . . . . . . . 12 9.1. Normative References . . . . . . . . . . . . . . . . . . 13
9.2. Informative References . . . . . . . . . . . . . . . . . 13 9.2. Informative References . . . . . . . . . . . . . . . . . 14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14
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
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 RFC such as the Internet Protocol Support Profile (IPSP) [IPSP], and RFC
7668, respectively. Bluetooth 4.0 only supports Bluetooth LE 7668, respectively. Bluetooth 4.0 only supports Bluetooth LE
networks that follow the star topology. In consequence, RFC 7668 was networks that follow the star topology. In consequence, RFC 7668 was
specifically developed and optimized for that type of network specifically developed and optimized for that type of network
topology. However, subsequent Bluetooth specifications allow the topology. However, the functionality described in RFC 7668 is not
formation of extended topologies [BTCorev4.1], such as the mesh sufficient and would fail to enable an IPv6 mesh over Bluetooth LE
topology. The functionality described in RFC 7668 is not sufficient links. This document specifies mechanisms that are needed to enable
and would fail to enable IPv6 over mesh networks composed of IPv6 mesh over Bluetooth LE links. This document does not specify
Bluetooth LE links. This document specifies the mechanisms needed to the routing protocol to be used in an IPv6 mesh over Bluetooth LE
enable IPv6 over mesh networks composed of Bluetooth LE links. This links.
specification also allows to run IPv6 over Bluetooth LE star topology
networks, albeit without all the topology-specific optimizations
contained in RFC 7668.
1.1. Terminology and Requirements Language 1.1. Terminology and Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119]. document are to be interpreted as described in RFC 2119 [RFC2119].
The terms 6LoWPAN Node (6LN), 6LoWPAN Router (6LR) and 6LoWPAN Border The terms 6LoWPAN Node (6LN), 6LoWPAN Router (6LR) and 6LoWPAN Border
Router (6LBR) are defined as in [RFC6775], with an addition that Router (6LBR) are defined as in [RFC6775], with an addition that
Bluetooth LE central and Bluetooth LE peripheral (see Section 2) can Bluetooth LE central and Bluetooth LE peripheral (see Section 2) can
both be adopted by a 6LN, a 6LR or a 6LBR. both be adopted by a 6LN, a 6LR or a 6LBR.
2. Bluetooth LE Networks and the IPSP 2. Bluetooth LE Networks and the IPSP
Bluetooth LE defines two Generic Access Profile (GAP) roles of Bluetooth LE defines two Generic Access Profile (GAP) roles of
relevance herein: the Bluetooth LE central role and the Bluetooth LE relevance herein: the Bluetooth LE central role and the Bluetooth LE
peripheral role. A device in the central role, which is called peripheral role. A device in the central role, which is called
central from now on, has traditionally been able to manage multiple central from now on, has traditionally been able to manage multiple
simultaneous connections with a number of devices in the peripheral simultaneous connections with a number of devices in the peripheral
role, called peripherals hereinafter. Bluetooth 4.1 introduced the role, called peripherals hereinafter. Bluetooth 4.1 (now deprecated)
possibility for a peripheral to be connected to more than one central introduced the possibility for a peripheral to be connected to more
simultaneously, therefore allowing extended topologies beyond the than one central simultaneously, therefore allowing extended
star topology for a Bluetooth LE network. In addition, a device may topologies beyond the star topology for a Bluetooth LE network. In
simultaneously be a central in a set of link layer connections, as addition, a device may simultaneously be a central in a set of link
well as a peripheral in others. On the other hand, the IPSP enables layer connections, as well as a peripheral in others. On the other
discovery of IP-enabled devices and the establishment of a link layer hand, the IPSP enables discovery of IP-enabled devices and the
connection for transporting IPv6 packets. The IPSP defines the Node establishment of a link layer connection for transporting IPv6
and Router roles for devices that consume/originate IPv6 packets and packets. The IPSP defines the Node and Router roles for devices that
for devices that can route IPv6 packets, respectively. Consistently consume/originate IPv6 packets and for devices that can route IPv6
with Bluetooth 4.1, a device may implement both roles simultaneously. packets, respectively. Consistently with Bluetooth 4.1 and
subsequent Bluetooth versions (e.g. Bluetooth 4.2 [BTCorev4.2] or
subsequent), 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 are established between neighboring where link layer connections are established between neighboring
IPv6-enabled devices (see Section 3.3.2, item 3.b)). The IPv6 IPv6-enabled devices (see Section 3.3.2, item 3.b)). The IPv6
forwarding devices of the mesh have to implement both Node and Router forwarding devices of the mesh have to implement both Node and Router
roles, while simpler leaf-only nodes can implement only the Node roles, while simpler leaf-only nodes can implement only the Node
role. In an IPv6-enabled mesh of Bluetooth LE links, a node is a role. In an IPv6 mesh over Bluetooth LE links, a node is a neighbor
neighbor of another node, and vice versa, if a link layer connection of another node, and vice versa, if a link layer connection has been
has been established between both by using the IPSP functionality for 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.
3. Specification of IPv6 mesh over Bluetooth LE networks 3. Specification of IPv6 mesh over Bluetooth LE links
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 links. 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 over Bluetooth LE") is now adapted
mesh networks of Bluetooth LE links, and b) the protocol stack for for IPv6 mesh over Bluetooth LE links, and b) the protocol stack for
IPv6 mesh networks of Bluetooth LE links includes IPv6 routing IPv6 mesh over Bluetooth LE links includes IPv6 routing
functionality. functionality.
+------------------------------------+ +------------------------------------+
| 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 Bluetooh LE |
+---------+--+------------------------------------+ +---------+--+------------------------------------+
| Bluetooth LE L2CAP | | Bluetooth LE L2CAP |
- - +-------------------------------------------------+- - - HCI - - +-------------------------------------------------+- - - HCI
| Bluetooth LE Link Layer | | Bluetooth LE Link Layer |
+-------------------------------------------------+ +-------------------------------------------------+
| Bluetooth LE Physical | | Bluetooth LE Physical |
+-------------------------------------------------+ +-------------------------------------------------+
Figure 1: Protocol stack for IPv6 mesh over Bluetooth LE. Figure 1: Protocol stack for IPv6 mesh over Bluetooth LE links.
Bluetooth 4.2 defines a default MTU for Bluetooth LE of 251 bytes.
Excluding the L2CAP header of 4 bytes, a protocol data unit (PDU)
size of 247 bytes is available for the layer above L2CAP. (Note:
earlier Bluetooth LE versions offered a maximum amount of 23 bytes
for the layer atop L2CAP.) The L2CAP provides a fragmentation and
reassembly solution for transmitting or receiving larger PDUs. At
each link, the IPSP defines means for negotiating a link-layer
connection that provides an MTU of 1280 octets or higher for the IPv6
layer [IPSP]. The link-layer MTU is negotiated separately for each
direction. Implementations that require an equal link-layer MTU for
the two directions SHALL use the smallest of the possibly different
MTU values.
Note that this specification allows using different MTUs in different
links. If an implementation requires use of the same MTU on every
one of its links, and a new node with a smaller MTU is added to the
network, a renegotiation of one or more links can occur. In the
worst case, the renegotiations could cascade network-wide. In that
case, implementers need to assess the impact of such phenomenon.
Similarly to RFC 7668, fragmentation functionality from 6LoWPAN
standards is not used for IPv6 mesh over Bluetooth LE links.
Bluetooth LE's fragmentation support provided by L2CAP is used when
necessary.
3.2. Subnet model 3.2. Subnet model
For IPv6 mesh over Bluetooth LE, a multilink model has been chosen, For IPv6 mesh over Bluetooth LE links, a multilink model has been
as further illustrated in Figure 2. As IPv6 over Bluetooth LE is chosen, as further illustrated in Figure 2. As IPv6 over Bluetooth
intended for constrained nodes, and for Internet of Things use cases LE is intended for constrained nodes, and for Internet of Things use
and environments, the complexity of implementing a separate subnet on cases and environments, the complexity of implementing a separate
each peripheral-central link and routing between the subnets appears subnet on each peripheral-central link and routing between the
to be excessive. In this specification, the benefits of treating the subnets appears to be excessive. In this specification, the benefits
collection of point-to-point links between a central and its of treating the collection of point-to-point links between a central
connected peripherals as a single multilink subnet rather than a and its connected peripherals as a single multilink subnet rather
multiplicity of separate subnets are considered to outweigh the than a multiplicity of separate subnets are considered to outweigh
multilink model's drawbacks as described in [RFC4903]. the multilink model's drawbacks as described in [RFC4903].
/ /
.--------------------------------. / .--------------------------------. /
/ 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 / \
skipping to change at page 5, line 27 skipping to change at page 5, line 47
<------------ Subnet -----------------><---- IPv6 connection --> <------------ Subnet -----------------><---- IPv6 connection -->
to the Internet to the Internet
Figure 2: Example of an IPv6 mesh over a Bluetooth LE network Figure 2: Example of an IPv6 mesh over a Bluetooth LE network
connected to the Internet connected to the Internet
One or more 6LBRs are connected to the Internet. 6LNs are connected 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 to the network through a 6LR or a 6LBR. A prefix is used on the
whole subnet. whole subnet.
IPv6 mesh networks over Bluetooth LE MUST follow a route-over IPv6 mesh over Bluetooth LE links MUST follow a route-over approach.
approach. This document does not specify the routing protocol to be This document does not specify the routing protocol to be used in an
used in an IPv6 mesh over Bluetooth LE. IPv6 mesh over Bluetooth LE links.
3.3. Link model 3.3. Link model
3.3.1. Stateless address autoconfiguration 3.3.1. Stateless address autoconfiguration
6LN, 6LR and 6LBR IPv6 addresses in an IPv6 mesh over Bluetooth LE 6LN, 6LR and 6LBR IPv6 addresses in an IPv6 mesh over Bluetooth LE
are configured as per section 3.2.2 of RFC 7668. links are configured as per section 3.2.2 of RFC 7668.
Multihop DAD functionality as defined in section 8.2 of RFC 6775, or Multihop DAD functionality as defined in section 8.2 of RFC 6775 and
some substitute mechanism (see section 3.3.2), MUST be supported. updated by RFC 8505, or some substitute mechanism (see section
3.3.2), MUST be supported.
3.3.2. Neighbor Discovery 3.3.2. Neighbor Discovery
'Neighbor Discovery Optimization for IPv6 over Low-Power Wireless 'Neighbor Discovery Optimization for IPv6 over Low-Power Wireless
Personal Area Networks (6LoWPANs)' [RFC6775] describes the neighbor Personal Area Networks (6LoWPANs)' [RFC6775], subsequently updated by
discovery approach as adapted for use in several 6LoWPAN topologies, 'Registration Extensions for IPv6 over Low-Power Wireless Personal
including the mesh topology. The route-over functionality of RFC Area Network (6LoWPAN) Neighbor Discovery' [RFC8505], describes the
6775 MUST be supported. neighbor discovery functionality adapted for use in several 6LoWPAN
topologies, including the mesh topology. The route-over
functionality of RFC 6775 and RFC 8505 MUST be supported.
The following aspects of the Neighbor Discovery optimizations The following aspects of the Neighbor Discovery optimizations for
[RFC6775] are applicable to Bluetooth LE 6LNs: 6LoWPAN [RFC6775],[RFC8505] are applicable to Bluetooth LE 6LNs:
1. A Bluetooth LE 6LN MUST NOT register its link-local address. A 1. A Bluetooth LE host MUST register its non-link-local addresses
Bluetooth LE host MUST register its non-link-local addresses with its with its routers by sending a Neighbor Solicitation (NS) message with
routers by sending a Neighbor Solicitation (NS) message with the the Extended Address Registration Option (EARO) and process the
Address Registration Option (ARO) and process the Neighbor Neighbor Advertisement (NA) accordingly. The NS with the EARO option
Advertisement (NA) accordingly. The NS with the ARO option MUST be MUST be sent irrespective of the method used to generate the IID.
sent irrespective of the method used to generate the IID. The ARO The EARO option includes a Registration Ownership Verifier (ROVR)
option requires use of an EUI-64 identifier [RFC6775]. In the case field [RFC8505]. In the case of Bluetooth LE, by default the ROVR
of Bluetooth LE, the field SHALL be filled with the 48-bit device field is filled with the 48-bit device address used by the Bluetooth
address used by the Bluetooth LE node converted into 64-bit Modified LE node converted into 64-bit Modified EUI-64 format [RFC4291].
EUI-64 format [RFC4291]. Optionally, a cryptographic ID (see [I-D.ietf-6lo-ap-nd] MAY be
placed in the ROVR field. If a cryptographic ID is used, address
registration and multihop DAD formats and procedures defined in
[I-D.ietf-6lo-ap-nd] MUST be used, unless an alternative mechanism
offering equivalent protection is used. As per RFC 8505, a 6LN MUST
NOT register its link-local address.
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 [RFC6775], and Section 5.6 of [RFC8505].
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: a) Routers SHALL of RFC 6775, and updated by RFC 8505. However, as per this
NOT use multicast NSs to discover other routers' link layer specification: a) Routers SHALL NOT use multicast NSs to discover
addresses. b) As per section 6.2 of RFC 6775, in a dynamic other routers' link layer addresses. b) As per section 6.2 of RFC
configuration scenario, a 6LR comes up as a non-router and waits to 6775, in a dynamic configuration scenario, a 6LR comes up as a non-
receive a Router Advertisement for configuring its own interface router and waits to receive a Router Advertisement for configuring
address first, before setting its interfaces to be advertising its own interface address first, before setting its interfaces to be
interfaces and turning into a router. In order to support such advertising interfaces and turning into a router. In order to
operation in an IPv6-enabled mesh of Bluetooth LE links, a 6LR first support such operation in an IPv6 mesh over Bluetooth LE links, a 6LR
uses the IPSP Node role only. Once the 6LR has established a first uses the IPSP Node role only. Once the 6LR has established a
connection with another node previously running as a router, and connection with another node previously running as a router, and
receives a Router Advertisement from that router, the 6LR configures receives a Router Advertisement from that router, the 6LR configures
its own interface address, it turns into a router, and it runs as an 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 IPSP Router. A 6LBR uses the IPSP Router role since the 6LBR is
initialized. See an example in the Appendix. 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, and
updated by RFC 8505.
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). RFC 8505 updates those mechanisms and the related
features described in sections 8.1 and 8.2 of RFC 6775 unless some message formats. Implementations of this specification MUST support
alternative ("substitute") from some other specification is the features described in sections 8.1 and 8.2 of RFC 6775, as
supported. updated by RFC 8505, unless some alternative ("substitute") from some
other specification is supported by the implementation.
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 MUST include a 6LoWPAN Context Option (6CO)
[RFC6775] matching each address prefix advertised via a Prefix [RFC6775] matching each address prefix advertised via a Prefix
Information Option (PIO) [RFC4861] for use in stateless address Information Option (PIO) [RFC4861] for use in stateless address
autoconfiguration. autoconfiguration.
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 a mesh exploit the star topology and ARO, cannot be generalized in an IPv6
network composed of Bluetooth LE links. Still, a subset of those mesh over Bluetooth LE links. Still, a subset of those optimizations
optimizations can be applied in some cases in such a network. In can be applied in some cases in such a network. In particular, the
particular, the latter comprise link-local interactions, non-link- latter comprise link-local interactions, non-link- local packet
local packet transmissions originated and performed by a 6LN, and transmissions originated and performed by a 6LN, and non-link-local
non-link-local packets transmitted (but not necessarily originated) packets transmitted (but not necessarily originated) by the neighbor
by the neighbor of a 6LN to that 6LN. For the rest of packet of a 6LN to that 6LN. For the rest of packet transmissions, context-
transmissions, context-based compression MAY be used. based 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).
When a 6LN transmits a packet, with a non-link-local source address A 6LN SHOULD register its non-link-local address with ARO in the
that the 6LN has registered with ARO in the next-hop router for the next-hop router. Note that in some cases (e.g. very short-lived
indicated prefix, the source address MUST be fully elided if it is connections) it may not be worthwhile for a 6LN to send an NS with
the latest address that the 6LN has registered for the indicated ARO for registering its address. When a 6LN transmits a packet, with
prefix (SAC=1, SAM=11). If the source non-link-local address is not a non-link-local source address that the 6LN has registered with ARO
the latest registered by the 6LN, then the 64-bits of the IID SHALL in the next-hop router for the indicated prefix, the source address
be fully carried in-line (SAC=1, SAM=01) or if the first 48-bits of MUST be fully elided if it is the latest address that the 6LN has
the IID match with the latest address registered by the 6LN, then the registered for the indicated prefix (SAC=1, SAM=11). If the source
last 16-bits of the IID SHALL be carried in-line (SAC=1, SAM=10). 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- 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 ARO 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
has to replicate the packet and unicast it on each link. However, has to replicate the packet and unicast it on each link. However,
this may not be energy efficient, and particular care must be taken this may 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 if the node is battery powered. A router (i.e. a 6LR or a 6LBR) MUST
keep track of neighboring multicast listeners, and it MUST NOT keep track of neighboring multicast listeners, and it MUST NOT
skipping to change at page 8, line 27 skipping to change at page 9, line 13
listeners for multicast groups the packets belong to. listeners for multicast groups the packets belong to.
4. IANA Considerations 4. IANA Considerations
There are no IANA considerations related to this document. There are no IANA considerations related to this document.
5. Security Considerations 5. Security Considerations
The security considerations in RFC 7668 apply. The security considerations in RFC 7668 apply.
IPv6 mesh networks over Bluetooth LE require a routing protocol to IPv6 mesh over Bluetooth LE links requires a routing protocol to find
find end-to-end paths. Unfortunately, the routing protocol may end-to-end paths. Unfortunately, the routing protocol may generate
generate additional opportunities for threats and attacks to the additional opportunities for threats and attacks to the network.
network.
RFC 7416 [RFC 7416] provides a systematic overview of threats and RFC 7416 [RFC 7416] provides a systematic overview of threats 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 (RPL), as well as countermeasures. In that document, described
threats and attacks comprise threats due to failures to authenticate, threats and attacks comprise threats due to failures to authenticate,
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 links, the guidance of RFC 7416
7416 is useful when RPL is used in such scenarios. Furthermore, such 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.
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 a registered-address-to-ROVR mapping could
perform address theft and impersonation attacks. Use of Address
Protected Neighbor Discovery [I-D.ietf-6lo-ap-nd] provides protection
against such attacks.
6. Contributors 6. Contributors
Carlo Alberto Boano (Graz University of Technology) contributed to Carlo Alberto Boano (Graz University of Technology) contributed to
the design and validation of this document. the design and validation of this document.
7. Acknowledgements 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, Martin Turon,
for their comments, which helped improve the document. Bilhanan Silverajan, Rahul Jadhav and Pascal Thubert 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 projects
TEC2012-32531, and FEDER. TEC2012-32531, TEC2016-79988-P and FEDER.
8. Appendix 8. Appendix
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-enabled mesh of establishment and use of IPSP roles in an IPv6 mesh over Bluetooth LE
Bluetooth LE links that uses dynamic configuration. The example links that uses dynamic configuration. The example follows text in
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.
The following text describes the different steps as time evolves, in The following text describes the different steps as time evolves, in
the example. Note that other sequences of events that may lead to the example. Note that other sequences of events that may lead to
the same final scenario are also possible. the same final scenario are also possible.
At the beginning, the 6LBR starts running as an IPSP Router, whereas At the beginning, the 6LBR starts running as an IPSP Router, whereas
skipping to change at page 12, line 6 skipping to change at page 12, line 41
/ \ / \
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)
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-enabled mesh of Bluetooth LE links. roles in an IPv6 mesh over Bluetooth LE links.
9. References 9. References
9.1. Normative References 9.1. Normative References
[BTCorev4.1] [BTCorev4.2]
Bluetooth Special Interest Group, "Bluetooth Core Bluetooth Special Interest Group, "Bluetooth Core
Specification Version 4.1", December 2013, Specification Version 4.2", December 2014,
<https://www.bluetooth.org/en-us/specification/ <https://www.bluetooth.com/specifications/
adopted-specifications>. archived-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 13, line 5 skipping to change at page 14, 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>.
[RFC8505] Thubert, P., Ed., Nordmark, E., Chakrabarti, S., and C.
Perkins, "Registration Extensions for IPv6 over Low-Power
Wireless Personal Area Network (6LoWPAN) Neighbor
Discovery", RFC 8505, DOI 10.17487/RFC8505, November 2018,
<https://www.rfc-editor.org/info/rfc8505>.
9.2. Informative References 9.2. Informative 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-ap-nd]
Thubert, P., Sarikaya, B., Sethi, M., and R. Struik,
"Address Protected Neighbor Discovery for Low-power and
Lossy Networks", draft-ietf-6lo-ap-nd-11 (work in
progress), February 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. 43 change blocks. 
135 lines changed or deleted 199 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/