rfc9159.original   rfc9159.txt 
6Lo Working Group C. Gomez Internet Engineering Task Force (IETF) C. Gomez
Internet-Draft S. Darroudi Request for Comments: 9159 S.M. Darroudi
Intended status: Standards Track Universitat Politecnica de Catalunya Category: Standards Track Universitat Politecnica de Catalunya
Expires: October 24, 2021 T. Savolainen ISSN: 2070-1721 T. Savolainen
Unaffiliated Unaffiliated
M. Spoerk M. Spoerk
Graz University of Technology Graz University of Technology
April 22, 2021 November 2021
IPv6 Mesh over BLUETOOTH(R) Low Energy using IPSP IPv6 Mesh over BLUETOOTH(R) Low Energy Using the Internet Protocol
draft-ietf-6lo-blemesh-10 Support Profile (IPSP)
Abstract Abstract
RFC 7668 describes the adaptation of 6LoWPAN techniques to enable RFC 7668 describes the adaptation of IPv6 over Low-Power Wireless
IPv6 over Bluetooth low energy networks that follow the star Personal Area Network (6LoWPAN) techniques to enable IPv6 over
Bluetooth Low Energy (Bluetooth LE) 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 LE
Energy links established by using the Bluetooth Internet Protocol links established by using the Bluetooth Internet Protocol Support
Support Profile. This document does not specify the routing protocol Profile (IPSP). This document does not specify the routing protocol
to be used in an IPv6 mesh over Bluetooth LE links. 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 is an Internet Standards Track document.
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 https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months This document is a product of the Internet Engineering Task Force
and may be updated, replaced, or obsoleted by other documents at any (IETF). It represents the consensus of the IETF community. It has
time. It is inappropriate to use Internet-Drafts as reference received public review and has been approved for publication by the
material or to cite them other than as "work in progress." Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 7841.
This Internet-Draft will expire on October 24, 2021. Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
https://www.rfc-editor.org/info/rfc9159.
Copyright Notice Copyright Notice
Copyright (c) 2021 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 Revised BSD License text as described in Section 4.e of the
the Trust Legal Provisions and are provided without warranty as Trust Legal Provisions and are provided without warranty as described
described in the Simplified BSD License. in the Revised BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction
1.1. Terminology and Requirements Language . . . . . . . . . . 3 1.1. Terminology and Requirements Language
2. Bluetooth LE Networks and the IPSP . . . . . . . . . . . . . 3 2. Bluetooth LE Networks and the IPSP
3. Specification of IPv6 mesh over Bluetooth LE links . . . . . 4 3. Specification of IPv6 Mesh over Bluetooth LE Links
3.1. Protocol stack . . . . . . . . . . . . . . . . . . . . . 4 3.1. Protocol Stack
3.2. Subnet model . . . . . . . . . . . . . . . . . . . . . . 5 3.2. Subnet Model
3.3. Link model . . . . . . . . . . . . . . . . . . . . . . . 6 3.3. Link Model
3.3.1. Stateless address autoconfiguration . . . . . . . . . 6 3.3.1. Stateless Address Autoconfiguration
3.3.2. Neighbor Discovery . . . . . . . . . . . . . . . . . 6 3.3.2. Neighbor Discovery
3.3.3. Header compression . . . . . . . . . . . . . . . . . 8 3.3.3. Header Compression
3.3.4. Unicast and multicast mapping . . . . . . . . . . . . 9 3.3.4. Unicast and Multicast Mapping
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 4. IANA Considerations
5. Security Considerations . . . . . . . . . . . . . . . . . . . 9 5. Security Considerations
6. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 10 6. References
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10 6.1. Normative References
8. Appendix A: Bluetooth LE connection establishment example . . 10 6.2. Informative References
9. Appendix B: Node joining procedure . . . . . . . . . . . . . 13 Appendix A. Bluetooth LE Connection Establishment Example
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 Appendix B. Node-Joining Procedure
10.1. Normative References . . . . . . . . . . . . . . . . . . 14 Acknowledgements
10.2. Informative References . . . . . . . . . . . . . . . . . 15 Contributors
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 Authors' Addresses
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 [RFC7668], respectively. Bluetooth 4.0 only supports Bluetooth 7668 [RFC7668], respectively. Bluetooth 4.0 only supports Bluetooth
LE networks that follow the star topology. As a consequence, RFC LE networks that follow the star topology. As a consequence, RFC
7668 [RFC7668] was specifically developed and optimized for that type 7668 [RFC7668] was specifically developed and optimized for that type
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", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in "OPTIONAL" in this document are to be interpreted as described in
BCP14 RFC 2119 [RFC2119], RFC 8174 [RFC8174], when, and only when, BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
they appear in all capitals, as shown here. 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
Router (6LBR) are defined as in [RFC6775], with an addition that Border Router" (6LBR) are defined as in [RFC6775], with an addition
Bluetooth LE central and Bluetooth LE peripheral (see Section 2) can that Bluetooth LE central and Bluetooth LE peripheral (see Section 2)
both be adopted by a 6LN, a 6LR or a 6LBR. can 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. In Bluetooth 4.0, a device in the central role,
central from now on, has traditionally been able to manage multiple which is called "central" from now on, was 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 (now deprecated) role, called "peripherals" hereinafter. Bluetooth 4.1 (now
introduced the possibility for a peripheral to be connected to more deprecated) introduced the possibility for a peripheral to be
than one central simultaneously, therefore allowing extended connected to more than one central simultaneously, therefore allowing
topologies beyond the star topology for a Bluetooth LE network. In extended topologies beyond the star topology for a Bluetooth LE
addition, a device may simultaneously be a central in a set of link network [BTCorev4.1]. In addition, a device may simultaneously be a
layer connections, as well as a peripheral in others. 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 On the other hand, the IPSP enables discovery of IP-enabled devices
and the establishment of a link layer connection for transporting and the establishment of a link-layer connection for transporting
IPv6 packets. The IPSP defines the Node and Router roles for devices IPv6 packets. The IPSP defines the Node and Router roles for devices
that consume/originate IPv6 packets and for devices that can route that consume/originate IPv6 packets and for devices that can route
IPv6 packets, respectively. Consistently with Bluetooth 4.1 and IPv6 packets, respectively. Consistent with Bluetooth 4.1, Bluetooth
subsequent Bluetooth versions (e.g. Bluetooth 4.2 [BTCorev4.2] or 4.2 [BTCorev4.2], and subsequent Bluetooth versions, a device may
subsequent), a device may implement both roles simultaneously. 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, and an example in IPv6-enabled devices (see Section 3.3.2, item 3.b, and an example in
Appendix A)). The IPv6 forwarding devices of the mesh have to Appendix A). The IPv6 forwarding devices of the mesh have to
implement both IPSP Node and Router roles, while simpler leaf-only implement both IPSP Node and Router roles, while simpler leaf-only
nodes can implement only the Node role. In an IPv6 mesh over nodes can implement only the Node role. In an IPv6 mesh over
Bluetooth LE links, a node is a neighbor of another node, and vice Bluetooth LE links, a node is a neighbor of another node, and vice
versa, if a link layer connection has been established between both versa, if a link-layer connection has been established between both
by using the IPSP functionality for discovery and link layer by using the IPSP functionality for discovery and link-layer
connection establishment for IPv6 packet transport. connection establishment for IPv6 packet transport.
3. Specification of IPv6 mesh over Bluetooth LE links 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 links. The core Bluetooth LE protocol stack comprises two main LE links. The core Bluetooth LE protocol stack comprises two main
sections: the Controller, and the Host. The former includes the sections: the Controller and the Host. The former includes the
Physical Layer, and the Link Layer, whereas the latter is composed of Physical Layer and the Link Layer, whereas the latter is composed of
the Logical Link Control and Adaptation Protocol (L2CAP), the the Logical Link Control and Adaptation Protocol (L2CAP), the
Attribute Protocol (ATT), and the Generic Attribute Profile (GATT). Attribute Protocol (ATT), and the Generic Attribute Profile (GATT).
The Host and the Controller sections are connected by means of the The Host and the Controller sections are connected by means of the
Host-Controller Interface (HCI). A device that supports the IPSP Host-Controller Interface (HCI). A device that supports the IPSP
Node role instantiates one Internet Protocol Support Service (IPSS), Node role instantiates one Internet Protocol Support Service (IPSS),
which runs atop GATT. The protocol stack shown in Figure 1 shows two which runs atop GATT. The protocol stack shown in Figure 1 shows two
main differences with the IPv6 over Bluetooth LE stack in RFC 7668: main differences with the IPv6 over Bluetooth LE stack in [RFC7668]:
a) the adaptation layer below IPv6 (labelled as "6Lo for IPv6 mesh
over Bluetooth LE") is now adapted for IPv6 mesh over Bluetooth LE a) the adaptation layer below IPv6 (labeled as "6Lo for IPv6 mesh
links, and b) the protocol stack for IPv6 mesh over Bluetooth LE over Bluetooth LE") is now adapted for IPv6 mesh over Bluetooth
links includes IPv6 routing functionality. LE links, and
b) the protocol stack for IPv6 mesh over Bluetooth LE links includes
IPv6 routing 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 Bluetooth LE|
+---------+--+------------------------------------+ +---------+--+------------------------------------+
| Bluetooth LE L2CAP | | Bluetooth LE L2CAP |
HCI - - +-------------------------------------------------+ - - HCI - - +-------------------------------------------------+ - -
| Bluetooth LE Link Layer | | Bluetooth LE Link Layer |
+-------------------------------------------------+ +-------------------------------------------------+
| Bluetooth LE Physical Layer | | Bluetooth LE Physical Layer |
+-------------------------------------------------+ +-------------------------------------------------+
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]. As per the present specification, the MTU size for layer [IPSP]. As per the present specification, the MTU size for
IPv6 mesh over BLE links is 1280 octets. IPv6 mesh over BLE links is 1280 octets.
Similarly to RFC 7668, fragmentation functionality from 6LoWPAN Similarly to [RFC7668], 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. Bluetooth LE's fragmentation support provided by L2CAP is used.
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]. With the the multilink model's drawbacks as described in [RFC4903]. With the
multilink subnet model, the routers have to take on responsibility multilink subnet model, the routers have to take on the
for tracking multicast state and forwarding multicast in a loop-free responsibility of tracking the multicast state and forwarding
manner. Note that the route-over functionality defined in [RFC6775] multicast in a loop-free manner. Note that the route-over
is essential to enable the multilink subnet model for IPv6 mesh over functionality defined in [RFC6775] is essential to enabling the
Bluetooth LE links. 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. Note that, in some to the network through a 6LR or a 6LBR. Note that in some scenarios
scenarios, and/or for some time intervals, a 6LR may remain at the and/or for some time intervals, a 6LR may remain at the edge of the
edge of the network (e.g. the top left node in Figure 2). This may network (e.g., the top left node in Figure 2). This may happen when
happen when a 6LR has no neighboring 6LNs. A single Global Unicast a 6LR has no neighboring 6LNs. A single global unicast prefix is
prefix is used on the whole subnet. 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
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
links are configured as per section 3.2.2 of RFC 7668. links are configured as per Section 3.2.2 of [RFC7668].
Multihop Duplicate Address Detection (DAD) functionality as defined Multihop Duplicate Address Detection (DAD) functionality as defined
in section 8.2 of RFC 6775 and updated by RFC 8505, or some in Section 8.2 of [RFC6775] and updated by [RFC8505], or some
substitute mechanism (see section 3.3.2), MAY be supported. substitute mechanism (see Section 3.3.2), MAY 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], 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 [RFC6775] and [RFC8505] 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 MUST 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
the Extended Address Registration Option (EARO) and process the with the Extended Address Registration Option (EARO) and process
Neighbor Advertisement (NA) accordingly. The EARO option includes a the Neighbor Advertisement (NA) accordingly. The EARO option
Registration Ownership Verifier (ROVR) field [RFC8505]. In the case includes a Registration Ownership Verifier (ROVR) field
of Bluetooth LE, by default the ROVR field is filled with the 48-bit [RFC8505]. In the case of Bluetooth LE, by default, the ROVR
device address used by the Bluetooth LE node converted into 64-bit field is filled with the 48-bit device address used by the
Modified EUI-64 format [RFC4291]. Optionally, a cryptographic ID Bluetooth LE node converted into 64-bit Modified EUI-64 format
(see RFC 8928 [RFC8928]) MAY be placed in the ROVR field. If a [RFC4291]. Optionally, a cryptographic ID (see RFC 8928
cryptographic ID is used, address registration and multihop DAD [RFC8928]) MAY be placed in the ROVR field. If a cryptographic
formats and procedures defined in RFC 8928 MUST be used, unless an ID is used, address registration and multihop DAD formats and
alternative mechanism offering equivalent protection is used. procedures defined in [RFC8928] MUST be used unless an
alternative mechanism offering equivalent protection is used.
As per RFC 8505, a 6LN link-local address does not need to be unique As per [RFC8505], a 6LN link-local address does not need to be
in the multilink subnet. A link-local address only needs to be unique in the multilink subnet. A link-local address only needs
unique from the perspective of the two nodes that use it to to be unique from the perspective of the two nodes that use it to
communicate (e.g., the 6LN and the 6LR in an NS/NA exchange). communicate (e.g., the 6LN and the 6LR in an NS/NA exchange).
Therefore, the exchange of EDAR and EDAC messages between the 6LR and Therefore, the exchange of Extended Duplicate Address Request
a 6LBR, which ensures that an address is unique across the domain (EDAR) and Extended Duplicate Address Confirmation (EDAC)
covered by the 6LBR, does not need to take place for link-local messages between the 6LR and a 6LBR, which ensures that an
addresses. 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
7668). [RFC7668]).
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
MUST, respectively, follow Sections 5.3 and 5.4 of [RFC6775], and BLE MUST, respectively, follow Sections 5.3 and 5.4 of [RFC6775],
Section 5.6 of [RFC8505]. 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, and updated by RFC 8505. However, as per this of [RFC6775] and updated by [RFC8505]. However, as per this
specification: a) Routers SHALL NOT use multicast NSs to discover specification:
other routers' link layer addresses. b) As per section 6.2 of RFC
6775, in a dynamic configuration scenario, a 6LR comes up as a non-
router and waits to receive a Router Advertisement for configuring
its own interface address first, before setting its interfaces to be
advertising interfaces and turning into a router. In order to
support such operation in an IPv6 mesh over Bluetooth LE links, a 6LR
first uses the IPSP Node role only. Once the 6LR has established a
connection with another node currently running as a router, and
receives a Router Advertisement from that router, the 6LR configures
its own interface address, it turns into a router, and it runs as an
IPSP Router. In contrast with a 6LR, a 6LBR uses the IPSP Router
role since the 6LBR is initialized, that is, the 6LBR uses both the
IPSP Node and IPSP Router roles at all times. See an example in
Appendix B..
4. Border router behavior is described in Section 7 of RFC 6775, and a. Routers SHALL NOT use multicast NSs to discover other
updated by RFC 8505. routers' link-layer addresses.
RFC 6775 defines substitutable mechanisms for distributing prefixes b. As per Section 6.2 of [RFC6775], in a dynamic configuration
and context information (section 8.1 of RFC 6775), as well as for scenario, a 6LR comes up as a non-router and waits to receive
Duplicate Address Detection across a route-over 6LoWPAN (section 8.2 a Router Advertisement for configuring its own interface
of RFC 6775). RFC 8505 updates those mechanisms and the related address first before setting its interfaces to advertising
message formats. Implementations of this specification MUST either interfaces and turning into a router. In order to support
support the features described in sections 8.1 and 8.2 of RFC 6775, such an operation in an IPv6 mesh over Bluetooth LE links, a
as updated by RFC 8505, or some alternative ("substitute") mechanism. 6LR first uses the IPSP Node role only. Once the 6LR has
established a connection with another node currently running
as a router and receives a Router Advertisement from that
router, the 6LR configures its own interface address, turns
into a router, and runs as an IPSP Router. In contrast with
a 6LR, a 6LBR uses the IPSP Router role since the 6LBR is
initialized; that is, the 6LBR uses both the IPSP Node and
IPSP Router roles at all times. See an example in
Appendix B.
3.3.3. Header compression 4. Border router behavior is described in Section 7 of [RFC6775] and
updated by [RFC8505].
[RFC6775] defines substitutable mechanisms for distributing
prefixes and context information (Section 8.1 of [RFC6775]), as
well as for duplicate address detection across a route-over
6LoWPAN (Section 8.2 of [RFC6775]). [RFC8505] updates those
mechanisms and the related message formats. Implementations of
this specification MUST either support the features described in
Sections 8.1 and 8.2 of [RFC6775], as updated by [RFC8505] or
some alternative ("substitute") mechanism.
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 MAY include a 6LoWPAN Context Option (6CO) [RFC6775] Advertisement, it MAY include a 6LoWPAN Context Option (6CO)
matching each address prefix advertised via a Prefix Information [RFC6775] matching each address prefix advertised via a Prefix
Option (PIO) [RFC4861] for use in stateless address Information 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 the context is pre-provisioned or provided by out-
band means, as in these cases the in-band indication (6CO) becomes of-band means as, in these cases, the in-band indication (6CO)
superfluous. becomes superfluous.
The specific optimizations of RFC 7668 for header compression, which The specific optimizations of [RFC7668] for header compression, which
exploited the star topology and ARO (note that the latter has been exploited the star topology and Address Registration Option (ARO)
updated by EARO as per RFC 8505), cannot be generalized in an IPv6 (note that the latter has been updated by EARO as per [RFC8505]),
mesh over Bluetooth LE links. Still, a subset of those optimizations cannot be generalized in an IPv6 mesh over Bluetooth LE links.
can be applied in some cases in such a network. These cases comprise Still, a subset of those optimizations can be applied in some cases
link-local interactions, non-link-local packet transmissions in such a network. These cases comprise link-local interactions,
originated by a 6LN (i.e. the first hop from a 6LN), and non-link- non-link-local packet transmissions originated by a 6LN (i.e., the
local packets intended for a 6LN that are originated or forwarded by first hop from a 6LN), and non-link-local packets intended for a 6LN
a neighbor of that 6LN (i.e. the last hop toward a 6LN). For all that are originated or forwarded by a neighbor of that 6LN (i.e., the
other packet transmissions, context-based compression MAY be used. last hop toward a 6LN). For all other packet transmissions, context-
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 Interface Identifier (IID) if the source IPv6
address based on the sender's Bluetooth device address (SAC=0, address is the link-local address based on the sender's Bluetooth
SAM=11). The sender also MUST fully elide the destination IPv6 device address (SAC=0, SAM=11). The sender also MUST fully elide the
address if it is the link-local address based on the neighbor's destination IPv6 address if it is the link-local address based on the
Bluetooth device address (DAC=0, DAM=11). neighbor's Bluetooth device address (DAC=0, DAM=11).
When a 6LN transmits a packet, with a non-link-local source address When a 6LN transmits a packet with a non-link-local source address
that the 6LN has registered with EARO in the next-hop router for the that the 6LN has registered with EARO in the next-hop router for the
indicated prefix, the source address MUST be fully elided if it is indicated prefix, the source address MUST be fully elided if it is
the latest address that the 6LN has registered for the indicated 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 prefix (SAC=1, SAM=11). If the source non-link-local address is not
the latest registered by the 6LN, and the first 48 bits of the IID the latest registered by the 6LN and the first 48 bits of the IID
match with the latest address registered by the 6LN, then the last 16 match the latest address are registered by the 6LN, then the last 16
bits of the IID SHALL be carried in-line (SAC=1, SAM=10). Otherwise, bits of the IID SHALL be carried inline (SAC=1, SAM=10). Otherwise,
if the first 48 bits of the IID do not match, then the 64 bits of the if the first 48 bits of the IID do not match, then the 64 bits of the
IID SHALL be fully carried in-line (SAC=1, SAM=01). IID SHALL be fully carried inline (SAC=1, SAM=01).
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 EARO 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, and the first 48 bits of the IID match to not the latest registered and if the first 48 bits of the IID match
those of the latest registered address, then the last 16 bits of the those of the latest registered address, then the last 16 bits of the
IID SHALL be carried in-line (DAC=1, DAM=10). Otherwise, if the IID SHALL be carried inline (DAC=1, DAM=10). Otherwise, if the first
first 48 bits of the IID do not match, then the 64 bits of the IID 48 bits of the IID do not match, then the 64 bits of the IID SHALL be
SHALL be fully carried in-line (DAC=1, DAM=01). fully carried in-line (DAC=1, DAM=01).
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) 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 MUST keep track of neighboring multicast listeners, and it MUST NOT
forward multicast packets to neighbors that have not registered as forward multicast packets to neighbors that have not registered as
listeners for multicast groups to which the packets are destined. listeners for multicast groups to which the packets are destined.
4. IANA Considerations 4. IANA Considerations
There are no IANA considerations related to this document. This document has no IANA actions.
5. Security Considerations 5. Security Considerations
The security considerations in RFC 7668 apply. The security considerations in [RFC7668] apply.
IPv6 mesh over Bluetooth LE links requires a routing protocol to find IPv6 mesh over BLE requires a routing protocol to find end-to-end
end-to-end paths. Unfortunately, the routing protocol may generate paths. Unfortunately, the routing protocol may generate additional
additional opportunities for threats and attacks to the network. opportunities for threats and attacks to the network.
RFC 7416 [RFC7416] provides a systematic overview of threats and RFC 7416 [RFC7416] 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 links, the guidance of RFC 7416 used in IPv6 mesh over Bluetooth LE links, the guidance of [RFC7416]
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, The ROVR can be derived from the Bluetooth device address. However,
such a ROVR can be spoofed, and therefore, any node connected to the such a ROVR can be spoofed; therefore, any node connected to the
subnet and aware of a registered-address-to-ROVR mapping could subnet and aware of a registered-address-to-ROVR mapping could
perform address theft and impersonation attacks. Use of Address perform address theft and impersonation attacks. Use of Address
Protected Neighbor Discovery RFC 8928 [RFC8928] provides protection Protected Neighbor Discovery [RFC8928] provides protection against
against such attacks. such attacks.
6. Contributors 6. References
Carlo Alberto Boano (Graz University of Technology) contributed to 6.1. Normative References
the design and validation of this document.
7. Acknowledgements [BTCorev4.2]
Bluetooth, "Core Specification 4.2", 2 December 2014,
<https://www.bluetooth.com/specifications/specs/core-
specification-4-2/>.
The Bluetooth, Bluetooth Smart and Bluetooth Smart Ready marks are [IPSP] Bluetooth, "Internet Protocol Support Profile 1.0", 16
registered trademarks owned by Bluetooth SIG, Inc. December 2014,
<https://www.bluetooth.com/specifications/specs/internet-
protocol-support-profile-1-0/>.
The authors of this document are grateful to all RFC 7668 authors, [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
since this document borrows many concepts (albeit, with necessary Requirement Levels", BCP 14, RFC 2119,
extensions) from RFC 7668. DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
The authors also thank Alain Michaud, Mark Powell, Martin Turon, [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing
Bilhanan Silverajan, Rahul Jadhav, Pascal Thubert, Acee Lindem, Architecture", RFC 4291, DOI 10.17487/RFC4291, February
Catherine Meadows, and Dominique Barthel for their reviews and 2006, <https://www.rfc-editor.org/info/rfc4291>.
comments, which helped improve the document.
Carles Gomez has been supported in part by the Spanish Government [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
Ministerio de Economia y Competitividad through projects "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,
TEC2012-32531, TEC2016-79988-P, PID2019-106808RA-I00 and FEDER, and DOI 10.17487/RFC4861, September 2007,
Secretaria d'Universitats i Recerca del Departament d'Empresa i <https://www.rfc-editor.org/info/rfc4861>.
Coneixement de la Generalitat de Catalunya 2017 through grant SGR
376.
8. Appendix A: Bluetooth LE connection establishment example [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,
<https://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,
<https://www.rfc-editor.org/info/rfc6775>.
[RFC7668] Nieminen, J., Savolainen, T., Isomaki, M., Patil, B.,
Shelby, Z., and C. Gomez, "IPv6 over BLUETOOTH(R) Low
Energy", RFC 7668, DOI 10.17487/RFC7668, October 2015,
<https://www.rfc-editor.org/info/rfc7668>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[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>.
[RFC8928] Thubert, P., Ed., Sarikaya, B., Sethi, M., and R. Struik,
"Address-Protected Neighbor Discovery for Low-Power and
Lossy Networks", RFC 8928, DOI 10.17487/RFC8928, November
2020, <https://www.rfc-editor.org/info/rfc8928>.
6.2. Informative References
[BTCorev4.1]
Bluetooth, "Core Specification 4.1", 3 December 2013,
<https://www.bluetooth.com/specifications/specs/core-
specification-4-1/>.
[RFC4903] Thaler, D., "Multi-Link Subnet Issues", RFC 4903,
DOI 10.17487/RFC4903, June 2007,
<https://www.rfc-editor.org/info/rfc4903>.
[RFC7416] Tsao, T., Alexander, R., Dohler, M., Daza, V., Lozano, A.,
and M. Richardson, Ed., "A Security Threat Analysis for
the Routing Protocol for Low-Power and Lossy Networks
(RPLs)", RFC 7416, DOI 10.17487/RFC7416, January 2015,
<https://www.rfc-editor.org/info/rfc7416>.
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 BLE that
links that uses dynamic configuration. The example follows text in 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
as shown in Figure 3. Connectivity between the 6LNs and the 6LBR is 6LNs, as shown in Figure 3. Connectivity between the 6LNs and the
only possible via the 6LRs. 6LBR is only possible via the 6LRs.
The following text describes the different steps as time evolves, in The following text describes the different steps in the example as
the example. Note that other sequences of events that may lead to time evolves. 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
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
layer connections (and after reception of Router Advertisements from link-layer connections (and after reception of Router Advertisements
the 6LBR), the 6LRs start operating as routers, and also initiate the from the 6LBR), the 6LRs start operating as routers and also initiate
IPSP Router role (Step 4) (note: whether the IPSP Node role is kept the IPSP Router role (Step 4). (Note: whether the IPSP Node role is
running simultaneously is an implementation decision). Then, 6LNs kept running simultaneously is an implementation decision). Then,
start running the IPSP Node role (Step 5). Finally, the 6LRs 6LNs start running the IPSP Node role (Step 5). Finally, the 6LRs
discover presence of the 6LNs and establish connections with the discover the 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 13, line 23 skipping to change at line 630
/ \ / \
/ \ / \
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: 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. Appendix B: Node joining procedure Appendix B. Node-Joining Procedure
This appendix provides a diagram that illustrates the node joining This appendix provides a diagram that illustrates the node-joining
procedure. First of all, the joining node advertises its presence in procedure. First of all, the joining node advertises its presence in
order to allow establishing Bluetooth LE connections with neighbors order to allow establishment of Bluetooth LE connections with
that already belong to a network. The latter typically run as a 6LR neighbors that already belong to a network. The neighbors typically
or as a 6LBR. After Bluetooth LE connection establishment, the run as a 6LR or as a 6LBR. After Bluetooth LE connection
joining node starts acting as a 6LN. establishment, the joining node starts acting as a 6LN.
Figure 4 shows the sequence of messages that are exchanged by the 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 and a neighboring 6LR that already belongs to the network after the
establishment of a Bluetooth LE connection between both devices. establishment of a Bluetooth LE connection between both devices.
Initially, the 6LN sends an RS message (1). Then, the 6LR replies Initially, the 6LN sends a Router Solicitation (RS) message (1).
with an RA, which includes the PIO (2). After discovering the non- Then, the 6LR replies with an RA, which includes the PIO (2). After
link-local prefix in use in the network, the 6LN creates its non- discovering the non-link-local prefix in use in the network, the 6LN
link-local address, registers that address with EARO (3) in the 6LR, creates its non-link-local address and registers that address with
and multihop DAD is performed (4). The next step is the transmission EARO (3) in the 6LR, and then multihop DAD is performed (4). The
of the NA message sent by the 6LR in response to the NS previously next step is the transmission of the NA message sent by the 6LR in
sent by the 6LN (5). If the non-link-local address of the 6LN has response to the NS previously sent by the 6LN (5). If the non-link-
been successfully validated, the 6LN can operate as a member of the local address of the 6LN has been successfully validated, the 6LN can
network it has joined. operate as a member of the network it has joined.
(1) 6LN ----(RS)-------> 6LR (1) 6LN ----(RS)-------> 6LR
(2) 6LN <---(RA-PIO)---- 6LR (2) 6LN <---(RA-PIO)---- 6LR
(3) 6LN ----(NS-EARO)--> 6LR (3) 6LN ----(NS-EARO)--> 6LR
(4) [Multihop DAD procedure] (4) [Multihop DAD procedure]
(5) 6LN <---(NA)-------- 6LR (5) 6LN <---(NA)-------- 6LR
Figure 4: Message exchange diagram for a joining node Figure 4: Message Exchange Diagram for a Joining Node
10. References
10.1. Normative References
[BTCorev4.2]
Bluetooth Special Interest Group, "Bluetooth Core
Specification Version 4.2", December 2014,
<https://www.bluetooth.com/specifications/archived-
specifications>.
[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,
<https://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, <https://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,
<https://www.rfc-editor.org/info/rfc4861>.
[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,
<https://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,
<https://www.rfc-editor.org/info/rfc6775>.
[RFC7668] Nieminen, J., Savolainen, T., Isomaki, M., Patil, B.,
Shelby, Z., and C. Gomez, "IPv6 over BLUETOOTH(R) Low
Energy", RFC 7668, DOI 10.17487/RFC7668, October 2015,
<https://www.rfc-editor.org/info/rfc7668>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC Acknowledgements
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8505] Thubert, P., Ed., Nordmark, E., Chakrabarti, S., and C. The Bluetooth, Bluetooth Smart, and Bluetooth Smart Ready marks are
Perkins, "Registration Extensions for IPv6 over Low-Power registered trademarks owned by Bluetooth SIG, Inc.
Wireless Personal Area Network (6LoWPAN) Neighbor
Discovery", RFC 8505, DOI 10.17487/RFC8505, November 2018,
<https://www.rfc-editor.org/info/rfc8505>.
[RFC8928] Thubert, P., Ed., Sarikaya, B., Sethi, M., and R. Struik, The authors of this document are grateful to all authors of
"Address-Protected Neighbor Discovery for Low-Power and [RFC7668], since this document borrows many concepts (albeit with
Lossy Networks", RFC 8928, DOI 10.17487/RFC8928, November necessary extensions) from [RFC7668].
2020, <https://www.rfc-editor.org/info/rfc8928>.
10.2. Informative References The authors also thank Alain Michaud, Mark Powell, Martin Turon,
Bilhanan Silverajan, Rahul Jadhav, Pascal Thubert, Acee Lindem,
Catherine Meadows, and Dominique Barthel for their reviews and
comments, which helped improve the document.
[BTCorev4.1] Carles Gomez has been supported in part by the Spanish Government
Bluetooth Special Interest Group, "Bluetooth Core Ministerio de Economia y Competitividad through projects
Specification Version 4.1", December 2013, TEC2012-32531, TEC2016-79988-P, PID2019-106808RA-I00, and FEDER and
<https://www.bluetooth.org/en-us/specification/adopted- Secretaria d'Universitats i Recerca del Departament d'Empresa i
specifications>. Coneixement de la Generalitat de Catalunya 2017 through grant SGR
376.
[RFC4903] Thaler, D., "Multi-Link Subnet Issues", RFC 4903, Contributors
DOI 10.17487/RFC4903, June 2007,
<https://www.rfc-editor.org/info/rfc4903>.
[RFC7416] Tsao, T., Alexander, R., Dohler, M., Daza, V., Lozano, A., Carlo Alberto Boano (Graz University of Technology) contributed to
and M. Richardson, Ed., "A Security Threat Analysis for the design and validation of this document.
the Routing Protocol for Low-Power and Lossy Networks
(RPLs)", RFC 7416, DOI 10.17487/RFC7416, January 2015,
<https://www.rfc-editor.org/info/rfc7416>.
Authors' Addresses Authors' Addresses
Carles Gomez Carles Gomez
Universitat Politecnica de Catalunya Universitat Politecnica de Catalunya
C/Esteve Terradas, 7 C/Esteve Terradas, 7
Castelldefels 08860 08860 Castelldefels
Spain Spain
Email: carlesgo@entel.upc.edu Email: carlesgo@entel.upc.edu
Seyed Mahdi Darroudi Seyed Mahdi Darroudi
Universitat Politecnica de Catalunya Universitat Politecnica de Catalunya
C/Esteve Terradas, 7 C/Esteve Terradas, 7
Castelldefels 08860 08860 Castelldefels
Spain Spain
Email: sm.darroudi@entel.upc.edu Email: sm.darroudi@entel.upc.edu
Teemu Savolainen Teemu Savolainen
Unaffiliated Unaffiliated
Email: tsavo.stds@gmail.com 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 8010 Graz
Austria Austria
Email: michael.spoerk@tugraz.at Email: michael.spoerk@tugraz.at
 End of changes. 97 change blocks. 
334 lines changed or deleted 343 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/