draft-ietf-6lo-blemesh-09.txt   draft-ietf-6lo-blemesh-10.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: June 10, 2021 T. Savolainen Expires: October 24, 2021 T. Savolainen
DarkMatter Unaffiliated
M. Spoerk M. Spoerk
Graz University of Technology Graz University of Technology
December 7, 2020 April 22, 2021
IPv6 Mesh over BLUETOOTH(R) Low Energy using IPSP IPv6 Mesh over BLUETOOTH(R) Low Energy using IPSP
draft-ietf-6lo-blemesh-09 draft-ietf-6lo-blemesh-10
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 June 10, 2021. This Internet-Draft will expire on October 24, 2021.
Copyright Notice Copyright Notice
Copyright (c) 2020 IETF Trust and the persons identified as the Copyright (c) 2021 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
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 . . . . . . . . . . . . . . . . . 8 3.3.3. Header compression . . . . . . . . . . . . . . . . . 8
3.3.4. Unicast and multicast mapping . . . . . . . . . . . . 9 3.3.4. Unicast and multicast mapping . . . . . . . . . . . . 9
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
5. Security Considerations . . . . . . . . . . . . . . . . . . . 9 5. Security Considerations . . . . . . . . . . . . . . . . . . . 9
6. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 10 6. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 10
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10
8. Appendix A: Bluetooth LE connection establishment example . . 11 8. Appendix A: Bluetooth LE connection establishment example . . 10
9. Appendix B: Node joining procedure . . . . . . . . . . . . . 13 9. Appendix B: Node joining procedure . . . . . . . . . . . . . 13
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 14
10.1. Normative References . . . . . . . . . . . . . . . . . . 14 10.1. Normative References . . . . . . . . . . . . . . . . . . 14
10.2. Informative References . . . . . . . . . . . . . . . . . 15 10.2. Informative References . . . . . . . . . . . . . . . . . 15
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16
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
skipping to change at page 3, line 13 skipping to change at page 3, line 13
of network topology. However, the functionality described in RFC of network topology. However, the functionality described in RFC
7668 [RFC7668] is not sufficient and would fail to enable an IPv6 7668 [RFC7668] is not sufficient and would fail to enable an IPv6
mesh over Bluetooth LE links. This document specifies mechanisms mesh over Bluetooth LE links. This document specifies mechanisms
that are needed to enable IPv6 mesh over Bluetooth LE links. This that are needed to enable IPv6 mesh over Bluetooth LE links. This
document does not specify the routing protocol to be used in an IPv6 document does not specify the routing protocol to be used in an IPv6
mesh over Bluetooth LE links. mesh over Bluetooth LE links.
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", "NOT RECOMMENDED", "MAY", and
document are to be interpreted as described in BCP14 RFC 2119 "OPTIONAL" in this document are to be interpreted as described in
[RFC2119], RFC 8174 [RFC8174], when, and only when, they appear in BCP14 RFC 2119 [RFC2119], RFC 8174 [RFC8174], when, and only when,
all capitals, as shown here. they appear in all capitals, as shown here.
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
skipping to change at page 5, line 7 skipping to change at page 5, line 7
Figure 1: Protocol stack for IPv6 mesh over Bluetooth LE links. Figure 1: Protocol stack for IPv6 mesh over Bluetooth LE links.
Bluetooth 4.2 defines a default MTU for Bluetooth LE of 251 bytes. 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) Excluding the L2CAP header of 4 bytes, a protocol data unit (PDU)
size of 247 bytes is available for the layer above L2CAP. (Note: size of 247 bytes is available for the layer above L2CAP. (Note:
earlier Bluetooth LE versions offered a maximum amount of 23 bytes earlier Bluetooth LE versions offered a maximum amount of 23 bytes
for the layer atop L2CAP.) The L2CAP provides a fragmentation and for the layer atop L2CAP.) The L2CAP provides a fragmentation and
reassembly solution for transmitting or receiving larger PDUs. At reassembly solution for transmitting or receiving larger PDUs. At
each link, the IPSP defines means for negotiating a link-layer each link, the IPSP defines means for negotiating a link-layer
connection that provides an MTU of 1280 octets or higher for the IPv6 connection that provides an MTU of 1280 octets or higher for the IPv6
layer [IPSP]. For the sake of lightweight implementation and layer [IPSP]. As per the present specification, the MTU size for
operation, an MTU of 1280 octets is RECOMMENDED for IPv6 mesh over IPv6 mesh over BLE links is 1280 octets.
BLE links. 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 Similarly to RFC 7668, fragmentation functionality from 6LoWPAN
standards is not used for IPv6 mesh over Bluetooth LE links. standards is not used for IPv6 mesh over Bluetooth LE links.
Bluetooth LE's fragmentation support provided by L2CAP is used when Bluetooth LE's fragmentation support provided by L2CAP is used.
necessary.
3.2. Subnet model 3.2. Subnet model
For IPv6 mesh over Bluetooth LE links, a multilink model has been For IPv6 mesh over Bluetooth LE links, a multilink model has been
chosen, as further illustrated in Figure 2. As IPv6 over Bluetooth chosen, as further illustrated in Figure 2. As IPv6 over Bluetooth
LE is intended for constrained nodes, and for Internet of Things use LE is intended for constrained nodes, and for Internet of Things use
cases and environments, the complexity of implementing a separate cases and environments, the complexity of implementing a separate
subnet on each peripheral-central link and routing between the subnet on each peripheral-central link and routing between the
subnets appears to be excessive. In this specification, the benefits subnets appears to be excessive. In this specification, the benefits
of treating the collection of point-to-point links between a central of treating the collection of point-to-point links between a central
and its connected peripherals as a single multilink subnet rather and its connected peripherals as a single multilink subnet rather
than a multiplicity of separate subnets are considered to outweigh than a multiplicity of separate subnets are considered to outweigh
the multilink model's drawbacks as described in [RFC4903]. Note that the multilink model's drawbacks as described in [RFC4903]. With the
the route-over functionality defined in [RFC6775] is essential to multilink subnet model, the routers have to take on responsibility
enable the multilink subnet model for IPv6 mesh over Bluetooth LE for tracking multicast state and forwarding multicast in a loop-free
links. manner. Note that the route-over functionality defined in [RFC6775]
is essential to enable the multilink subnet model for IPv6 mesh over
Bluetooth LE links.
/ /
.--------------------------------. / /
/ 6LR 6LN 6LN \ / 6LR 6LN 6LN /
/ \ \ \ \ / \ \ \ /
| \ \ \ | / \ \ \ /
| 6LN ----- 6LR --------- 6LR ------ 6LBR ----- | Internet 6LN ----- 6LR --------- 6LR ------ 6LBR ----- | Internet
| <--Link--> <---Link--->/<--Link->/ | | <--Link--> <---Link--->/<--Link->/ |
\ / / / \ / / \
\ 6LN ---- 6LR ----- 6LR / \ 6LN ---- 6LR ----- 6LR \
'--------------------------------' \ \
\ \
<------------ Subnet -----------------><---- IPv6 connection --> <------------ Subnet -----------------><---- IPv6 connection -->
to the Internet to the Internet
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 single Global Unicast to the network through a 6LR or a 6LBR. Note that, in some
scenarios, and/or for some time intervals, a 6LR may remain at the
edge of the network (e.g. the top left node in Figure 2). This may
happen when a 6LR has no neighboring 6LNs. A single Global Unicast
prefix is used on the whole subnet. prefix is used on the whole subnet.
IPv6 mesh over Bluetooth LE links MUST follow a route-over approach. IPv6 mesh over Bluetooth LE links MUST follow a route-over approach.
This document does not specify the routing protocol to be used in an This document does not specify the routing protocol to be used in an
IPv6 mesh over Bluetooth LE links. IPv6 mesh over Bluetooth LE links.
3.3. Link model 3.3. Link model
3.3.1. Stateless address autoconfiguration 3.3.1. Stateless address autoconfiguration
skipping to change at page 7, line 8 skipping to change at page 6, line 40
Personal Area Networks (6LoWPANs)' [RFC6775], subsequently updated by Personal Area Networks (6LoWPANs)' [RFC6775], subsequently updated by
'Registration Extensions for IPv6 over Low-Power Wireless Personal 'Registration Extensions for IPv6 over Low-Power Wireless Personal
Area Network (6LoWPAN) Neighbor Discovery' [RFC8505], describes the Area Network (6LoWPAN) Neighbor Discovery' [RFC8505], describes the
neighbor discovery functionality adapted for use in several 6LoWPAN neighbor discovery functionality adapted for use in several 6LoWPAN
topologies, including the mesh topology. The route-over topologies, including the mesh topology. The route-over
functionality of RFC 6775 and RFC 8505 MUST be supported. functionality of RFC 6775 and RFC 8505 MUST be supported.
The following aspects of the Neighbor Discovery optimizations for The following aspects of the Neighbor Discovery optimizations for
6LoWPAN [RFC6775],[RFC8505] are applicable to Bluetooth LE 6LNs: 6LoWPAN [RFC6775],[RFC8505] are applicable to Bluetooth LE 6LNs:
1. A Bluetooth LE 6LN SHOULD register its non-link-local addresses 1. A Bluetooth LE 6LN MUST register its non-link-local addresses
with its routers by sending a Neighbor Solicitation (NS) message with with its routers by sending a Neighbor Solicitation (NS) message with
the Extended Address Registration Option (EARO) and process the the Extended Address Registration Option (EARO) and process the
Neighbor Advertisement (NA) accordingly. Note that in some cases Neighbor Advertisement (NA) accordingly. The EARO option includes a
(e.g., very short-lived connections) it may not be worthwhile for a Registration Ownership Verifier (ROVR) field [RFC8505]. In the case
6LN to send an NS with EARO for registering its address. However, of Bluetooth LE, by default the ROVR field is filled with the 48-bit
the consequences of not registering the address (including non- device address used by the Bluetooth LE node converted into 64-bit
reachability of the 6LN, and absence of DAD) need to be carefully Modified EUI-64 format [RFC4291]. Optionally, a cryptographic ID
considered. The EARO option includes a Registration Ownership (see RFC 8928 [RFC8928]) MAY be placed in the ROVR field. If a
Verifier (ROVR) field [RFC8505]. In the case of Bluetooth LE, by cryptographic ID is used, address registration and multihop DAD
default the ROVR field is filled with the 48-bit device address used formats and procedures defined in RFC 8928 MUST be used, unless an
by the Bluetooth LE node converted into 64-bit Modified EUI-64 format alternative mechanism offering equivalent protection is used.
[RFC4291]. Optionally, a cryptographic ID (see RFC 8928 [RFC8928])
MAY be placed in the ROVR field. If a cryptographic ID is used, As per RFC 8505, a 6LN link-local address does not need to be unique
address registration and multihop DAD formats and procedures defined in the multilink subnet. A link-local address only needs to be
in RFC 8928 MUST be used, unless an alternative mechanism offering unique from the perspective of the two nodes that use it to
equivalent protection is used. As per RFC 8505, a 6LN MUST NOT communicate (e.g., the 6LN and the 6LR in an NS/NA exchange).
register its link-local address. Therefore, the exchange of EDAR and EDAC messages between the 6LR and
a 6LBR, which ensures that an address is unique across the domain
covered by the 6LBR, does not need to take place for link-local
addresses.
If the 6LN registers multiple addresses that are not based on the If the 6LN registers multiple addresses that are not based on the
Bluetooth device address using the same compression context, the Bluetooth device address using the same compression context, the
header compression efficiency may decrease, since only the last header compression efficiency may decrease, since only the last
registered address can be fully elided (see Section 3.2.4 of RFC registered address can be fully elided (see Section 3.2.4 of RFC
7668). 7668).
2. For sending Router Solicitations and processing Router 2. For sending Router Solicitations and processing Router
Advertisements, the hosts that participate in an IPv6 mesh over BLE Advertisements, the hosts that participate in an IPv6 mesh over BLE
MUST, respectively, follow Sections 5.3 and 5.4 of [RFC6775], and MUST, respectively, follow Sections 5.3 and 5.4 of [RFC6775], and
skipping to change at page 8, line 32 skipping to change at page 8, line 19
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 MAY include a 6LoWPAN Context Option (6CO) [RFC6775] Advertisement it MAY include a 6LoWPAN Context Option (6CO) [RFC6775]
matching each address prefix advertised via a Prefix Information matching each address prefix advertised via a Prefix Information
Option (PIO) [RFC4861] for use in stateless address Option (PIO) [RFC4861] for use in stateless address
autoconfiguration. Note that 6CO is not needed for context-based autoconfiguration. Note that 6CO is not needed for context-based
compression when context is pre-provisioned or provided by out-of- compression when context is pre-provisioned or provided by out-of-
band means. band means, as in these cases the in-band indication (6CO) becomes
superfluous.
The specific optimizations of RFC 7668 for header compression, which The specific optimizations of RFC 7668 for header compression, which
exploited the star topology and ARO (note that the latter has been 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 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. These cases comprise can be applied in some cases in such a network. These cases comprise
link-local interactions, non-link-local packet transmissions link-local interactions, non-link-local packet transmissions
originated by a 6LN (i.e. the first hop from a 6LN), and non-link- originated by a 6LN (i.e. the first hop from a 6LN), and non-link-
local packets intended for a 6LN that are originated or forwarded by local packets intended for a 6LN that are originated or forwarded by
a neighbor of that 6LN (i.e. the last hop toward a 6LN). For all a neighbor of that 6LN (i.e. the last hop toward a 6LN). For all
skipping to change at page 11, line 28 skipping to change at page 11, line 13
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
the rest of devices are not yet initialized (Step 1). Next, the 6LRs the rest of devices are not yet initialized (Step 1). Next, the 6LRs
start running as IPSP Nodes, i.e., they use Bluetooth LE start running as IPSP Nodes, i.e., they use Bluetooth LE
advertisement packets to announce their presence and support of IPv6 advertisement packets to announce their presence and support of IPv6
capabilities (Step 2). The 6LBR (already running as an IPSP Router) capabilities (Step 2). The 6LBR (already running as an IPSP Router)
discovers the presence of the 6LRs and establishes one Bluetooth LE discovers the presence of the 6LRs and establishes one Bluetooth LE
connection with each 6LR (Step 3). After establishment of those link connection with each 6LR (Step 3). After establishment of those link
layer connections (and after reception of Router Advertisements from layer connections (and after reception of Router Advertisements from
the 6LBR), Step 4, the 6LRs start operating as routers, and also the 6LBR), the 6LRs start operating as routers, and also initiate the
initiate the IPSP Router role (note: whether the IPSP Node role is IPSP Router role (Step 4) (note: whether the IPSP Node role is kept
kept running simultaneously is an implementation decision). Then, running simultaneously is an implementation decision). Then, 6LNs
6LNs start running the IPSP Node role (Step 5). Finally, the 6LRs start running the IPSP Node role (Step 5). Finally, the 6LRs
discover presence of the 6LNs and establish connections with the discover presence of the 6LNs and establish connections with the
latter (Step 6). latter (Step 6).
Step 1 Step 1
****** ******
6LBR 6LBR
(IPSP: Router) (IPSP: Router)
6LR 6LR 6LR 6LR
(not initialized) (not initialized) (not initialized) (not initialized)
skipping to change at page 16, line 34 skipping to change at page 16, line 24
Seyed Mahdi Darroudi Seyed Mahdi Darroudi
Universitat Politecnica de Catalunya 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
DarkMatter LLC Unaffiliated
Email: teemu.savolainen@darkmatter.ae Email: tsavo.stds@gmail.com
Michael Spoerk Michael Spoerk
Graz University of Technology Graz University of Technology
Inffeldgasse 16/I Inffeldgasse 16/I
Graz 8010 Graz 8010
Austria Austria
Email: michael.spoerk@tugraz.at Email: michael.spoerk@tugraz.at
 End of changes. 18 change blocks. 
63 lines changed or deleted 60 lines changed or added

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