idnits 2.17.1 draft-ietf-6lo-blemesh-09.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (December 7, 2020) is 1236 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Possible downref: Non-RFC (?) normative reference: ref. 'IPSP' Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 6Lo Working Group C. Gomez 3 Internet-Draft S. Darroudi 4 Intended status: Standards Track Universitat Politecnica de Catalunya 5 Expires: June 10, 2021 T. Savolainen 6 DarkMatter 7 M. Spoerk 8 Graz University of Technology 9 December 7, 2020 11 IPv6 Mesh over BLUETOOTH(R) Low Energy using IPSP 12 draft-ietf-6lo-blemesh-09 14 Abstract 16 RFC 7668 describes the adaptation of 6LoWPAN techniques to enable 17 IPv6 over Bluetooth low energy networks that follow the star 18 topology. However, recent Bluetooth specifications allow the 19 formation of extended topologies as well. This document specifies 20 mechanisms that are needed to enable IPv6 mesh over Bluetooth Low 21 Energy links established by using the Bluetooth Internet Protocol 22 Support Profile. This document does not specify the routing protocol 23 to be used in an IPv6 mesh over Bluetooth LE links. 25 Status of This Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at https://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on June 10, 2021. 42 Copyright Notice 44 Copyright (c) 2020 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (https://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 60 1.1. Terminology and Requirements Language . . . . . . . . . . 3 61 2. Bluetooth LE Networks and the IPSP . . . . . . . . . . . . . 3 62 3. Specification of IPv6 mesh over Bluetooth LE links . . . . . 4 63 3.1. Protocol stack . . . . . . . . . . . . . . . . . . . . . 4 64 3.2. Subnet model . . . . . . . . . . . . . . . . . . . . . . 5 65 3.3. Link model . . . . . . . . . . . . . . . . . . . . . . . 6 66 3.3.1. Stateless address autoconfiguration . . . . . . . . . 6 67 3.3.2. Neighbor Discovery . . . . . . . . . . . . . . . . . 6 68 3.3.3. Header compression . . . . . . . . . . . . . . . . . 8 69 3.3.4. Unicast and multicast mapping . . . . . . . . . . . . 9 70 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 71 5. Security Considerations . . . . . . . . . . . . . . . . . . . 9 72 6. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 10 73 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10 74 8. Appendix A: Bluetooth LE connection establishment example . . 11 75 9. Appendix B: Node joining procedure . . . . . . . . . . . . . 13 76 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 77 10.1. Normative References . . . . . . . . . . . . . . . . . . 14 78 10.2. Informative References . . . . . . . . . . . . . . . . . 15 79 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 81 1. Introduction 83 Bluetooth Low Energy (hereinafter, Bluetooth LE) was first introduced 84 in the Bluetooth 4.0 specification. Bluetooth LE (which has been 85 marketed as Bluetooth Smart) is a low-power wireless technology 86 designed for short-range control and monitoring applications. 87 Bluetooth LE is currently implemented in a wide range of consumer 88 electronics devices, such as smartphones and wearable devices. Given 89 the high potential of this technology for the Internet of Things, the 90 Bluetooth Special Interest Group (Bluetooth SIG) and the IETF have 91 produced specifications in order to enable IPv6 over Bluetooth LE, 92 such as the Internet Protocol Support Profile (IPSP) [IPSP], and RFC 93 7668 [RFC7668], respectively. Bluetooth 4.0 only supports Bluetooth 94 LE networks that follow the star topology. As a consequence, RFC 95 7668 [RFC7668] was specifically developed and optimized for that type 96 of network topology. However, the functionality described in RFC 97 7668 [RFC7668] is not sufficient and would fail to enable an IPv6 98 mesh over Bluetooth LE links. This document specifies mechanisms 99 that are needed to enable IPv6 mesh over Bluetooth LE links. This 100 document does not specify the routing protocol to be used in an IPv6 101 mesh over Bluetooth LE links. 103 1.1. Terminology and Requirements Language 105 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 106 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 107 document are to be interpreted as described in BCP14 RFC 2119 108 [RFC2119], RFC 8174 [RFC8174], when, and only when, they appear in 109 all capitals, as shown here. 111 The terms 6LoWPAN Node (6LN), 6LoWPAN Router (6LR) and 6LoWPAN Border 112 Router (6LBR) are defined as in [RFC6775], with an addition that 113 Bluetooth LE central and Bluetooth LE peripheral (see Section 2) can 114 both be adopted by a 6LN, a 6LR or a 6LBR. 116 2. Bluetooth LE Networks and the IPSP 118 Bluetooth LE defines two Generic Access Profile (GAP) roles of 119 relevance herein: the Bluetooth LE central role and the Bluetooth LE 120 peripheral role. A device in the central role, which is called 121 central from now on, has traditionally been able to manage multiple 122 simultaneous connections with a number of devices in the peripheral 123 role, called peripherals hereinafter. Bluetooth 4.1 (now deprecated) 124 introduced the possibility for a peripheral to be connected to more 125 than one central simultaneously, therefore allowing extended 126 topologies beyond the star topology for a Bluetooth LE network. In 127 addition, a device may simultaneously be a central in a set of link 128 layer connections, as well as a peripheral in others. 130 On the other hand, the IPSP enables discovery of IP-enabled devices 131 and the establishment of a link layer connection for transporting 132 IPv6 packets. The IPSP defines the Node and Router roles for devices 133 that consume/originate IPv6 packets and for devices that can route 134 IPv6 packets, respectively. Consistently with Bluetooth 4.1 and 135 subsequent Bluetooth versions (e.g. Bluetooth 4.2 [BTCorev4.2] or 136 subsequent), a device may implement both roles simultaneously. 138 This document assumes a mesh network composed of Bluetooth LE links, 139 where link layer connections are established between neighboring 140 IPv6-enabled devices (see Section 3.3.2, item 3.b, and an example in 141 Appendix A)). The IPv6 forwarding devices of the mesh have to 142 implement both IPSP Node and Router roles, while simpler leaf-only 143 nodes can implement only the Node role. In an IPv6 mesh over 144 Bluetooth LE links, a node is a neighbor of another node, and vice 145 versa, if a link layer connection has been established between both 146 by using the IPSP functionality for discovery and link layer 147 connection establishment for IPv6 packet transport. 149 3. Specification of IPv6 mesh over Bluetooth LE links 151 3.1. Protocol stack 153 Figure 1 illustrates the protocol stack for IPv6 mesh over Bluetooth 154 LE links. The core Bluetooth LE protocol stack comprises two main 155 sections: the Controller, and the Host. The former includes the 156 Physical Layer, and the Link Layer, whereas the latter is composed of 157 the Logical Link Control and Adaptation Protocol (L2CAP), the 158 Attribute Protocol (ATT), and the Generic Attribute Profile (GATT). 159 The Host and the Controller sections are connected by means of the 160 Host-Controller Interface (HCI). A device that supports the IPSP 161 Node role instantiates one Internet Protocol Support Service (IPSS), 162 which runs atop GATT. The protocol stack shown in Figure 1 shows two 163 main differences with the IPv6 over Bluetooth LE stack in RFC 7668: 164 a) the adaptation layer below IPv6 (labelled as "6Lo for IPv6 mesh 165 over Bluetooth LE") is now adapted for IPv6 mesh over Bluetooth LE 166 links, and b) the protocol stack for IPv6 mesh over Bluetooth LE 167 links includes IPv6 routing functionality. 169 +------------------------------------+ 170 | Application | 171 +---------+ +------------------------------------+ 172 | IPSS | | UDP/TCP/other | 173 +---------+ +------------------------------------+ 174 | GATT | | IPv6 |routing| | 175 +---------+ +------------------------------------+ 176 | ATT | | 6Lo for IPv6 mesh over Bluetooh LE | 177 +---------+--+------------------------------------+ 178 | Bluetooth LE L2CAP | 179 HCI - - +-------------------------------------------------+ - - 180 | Bluetooth LE Link Layer | 181 +-------------------------------------------------+ 182 | Bluetooth LE Physical Layer | 183 +-------------------------------------------------+ 185 Figure 1: Protocol stack for IPv6 mesh over Bluetooth LE links. 187 Bluetooth 4.2 defines a default MTU for Bluetooth LE of 251 bytes. 188 Excluding the L2CAP header of 4 bytes, a protocol data unit (PDU) 189 size of 247 bytes is available for the layer above L2CAP. (Note: 190 earlier Bluetooth LE versions offered a maximum amount of 23 bytes 191 for the layer atop L2CAP.) The L2CAP provides a fragmentation and 192 reassembly solution for transmitting or receiving larger PDUs. At 193 each link, the IPSP defines means for negotiating a link-layer 194 connection that provides an MTU of 1280 octets or higher for the IPv6 195 layer [IPSP]. For the sake of lightweight implementation and 196 operation, an MTU of 1280 octets is RECOMMENDED for IPv6 mesh over 197 BLE links. The link-layer MTU is negotiated separately for each 198 direction. Implementations that require an equal link-layer MTU for 199 the two directions SHALL use the smallest of the possibly different 200 MTU values. 202 Note that this specification allows using different MTUs in different 203 links. If an implementation requires use of the same MTU on every 204 one of its links, and a new node with a smaller MTU is added to the 205 network, a renegotiation of one or more links can occur. In the 206 worst case, the renegotiations could cascade network-wide. In that 207 case, implementers need to assess the impact of such phenomenon. 209 Similarly to RFC 7668, fragmentation functionality from 6LoWPAN 210 standards is not used for IPv6 mesh over Bluetooth LE links. 211 Bluetooth LE's fragmentation support provided by L2CAP is used when 212 necessary. 214 3.2. Subnet model 216 For IPv6 mesh over Bluetooth LE links, a multilink model has been 217 chosen, as further illustrated in Figure 2. As IPv6 over Bluetooth 218 LE is intended for constrained nodes, and for Internet of Things use 219 cases and environments, the complexity of implementing a separate 220 subnet on each peripheral-central link and routing between the 221 subnets appears to be excessive. In this specification, the benefits 222 of treating the collection of point-to-point links between a central 223 and its connected peripherals as a single multilink subnet rather 224 than a multiplicity of separate subnets are considered to outweigh 225 the multilink model's drawbacks as described in [RFC4903]. Note that 226 the route-over functionality defined in [RFC6775] is essential to 227 enable the multilink subnet model for IPv6 mesh over Bluetooth LE 228 links. 230 / 231 .--------------------------------. / 232 / 6LR 6LN 6LN \ / 233 / \ \ \ \ / 234 | \ \ \ | / 235 | 6LN ----- 6LR --------- 6LR ------ 6LBR ----- | Internet 236 | <--Link--> <---Link--->/<--Link->/ | | 237 \ / / / \ 238 \ 6LN ---- 6LR ----- 6LR / \ 239 '--------------------------------' \ 240 \ 242 <------------ Subnet -----------------><---- IPv6 connection --> 243 to the Internet 245 Figure 2: Example of an IPv6 mesh over a Bluetooth LE network 246 connected to the Internet 248 One or more 6LBRs are connected to the Internet. 6LNs are connected 249 to the network through a 6LR or a 6LBR. A single Global Unicast 250 prefix is used on the whole subnet. 252 IPv6 mesh over Bluetooth LE links MUST follow a route-over approach. 253 This document does not specify the routing protocol to be used in an 254 IPv6 mesh over Bluetooth LE links. 256 3.3. Link model 258 3.3.1. Stateless address autoconfiguration 260 6LN, 6LR, and 6LBR IPv6 addresses in an IPv6 mesh over Bluetooth LE 261 links are configured as per section 3.2.2 of RFC 7668. 263 Multihop Duplicate Address Detection (DAD) functionality as defined 264 in section 8.2 of RFC 6775 and updated by RFC 8505, or some 265 substitute mechanism (see section 3.3.2), MAY be supported. 267 3.3.2. Neighbor Discovery 269 'Neighbor Discovery Optimization for IPv6 over Low-Power Wireless 270 Personal Area Networks (6LoWPANs)' [RFC6775], subsequently updated by 271 'Registration Extensions for IPv6 over Low-Power Wireless Personal 272 Area Network (6LoWPAN) Neighbor Discovery' [RFC8505], describes the 273 neighbor discovery functionality adapted for use in several 6LoWPAN 274 topologies, including the mesh topology. The route-over 275 functionality of RFC 6775 and RFC 8505 MUST be supported. 277 The following aspects of the Neighbor Discovery optimizations for 278 6LoWPAN [RFC6775],[RFC8505] are applicable to Bluetooth LE 6LNs: 280 1. A Bluetooth LE 6LN SHOULD register its non-link-local addresses 281 with its routers by sending a Neighbor Solicitation (NS) message with 282 the Extended Address Registration Option (EARO) and process the 283 Neighbor Advertisement (NA) accordingly. Note that in some cases 284 (e.g., very short-lived connections) it may not be worthwhile for a 285 6LN to send an NS with EARO for registering its address. However, 286 the consequences of not registering the address (including non- 287 reachability of the 6LN, and absence of DAD) need to be carefully 288 considered. The EARO option includes a Registration Ownership 289 Verifier (ROVR) field [RFC8505]. In the case of Bluetooth LE, by 290 default the ROVR field is filled with the 48-bit device address used 291 by the Bluetooth LE node converted into 64-bit Modified EUI-64 format 292 [RFC4291]. Optionally, a cryptographic ID (see RFC 8928 [RFC8928]) 293 MAY be placed in the ROVR field. If a cryptographic ID is used, 294 address registration and multihop DAD formats and procedures defined 295 in RFC 8928 MUST be used, unless an alternative mechanism offering 296 equivalent protection is used. As per RFC 8505, a 6LN MUST NOT 297 register its link-local address. 299 If the 6LN registers multiple addresses that are not based on the 300 Bluetooth device address using the same compression context, the 301 header compression efficiency may decrease, since only the last 302 registered address can be fully elided (see Section 3.2.4 of RFC 303 7668). 305 2. For sending Router Solicitations and processing Router 306 Advertisements, the hosts that participate in an IPv6 mesh over BLE 307 MUST, respectively, follow Sections 5.3 and 5.4 of [RFC6775], and 308 Section 5.6 of [RFC8505]. 310 3. The router behavior for 6LRs and 6LBRs is described in Section 6 311 of RFC 6775, and updated by RFC 8505. However, as per this 312 specification: a) Routers SHALL NOT use multicast NSs to discover 313 other routers' link layer addresses. b) As per section 6.2 of RFC 314 6775, in a dynamic configuration scenario, a 6LR comes up as a non- 315 router and waits to receive a Router Advertisement for configuring 316 its own interface address first, before setting its interfaces to be 317 advertising interfaces and turning into a router. In order to 318 support such operation in an IPv6 mesh over Bluetooth LE links, a 6LR 319 first uses the IPSP Node role only. Once the 6LR has established a 320 connection with another node currently running as a router, and 321 receives a Router Advertisement from that router, the 6LR configures 322 its own interface address, it turns into a router, and it runs as an 323 IPSP Router. In contrast with a 6LR, a 6LBR uses the IPSP Router 324 role since the 6LBR is initialized, that is, the 6LBR uses both the 325 IPSP Node and IPSP Router roles at all times. See an example in 326 Appendix B.. 328 4. Border router behavior is described in Section 7 of RFC 6775, and 329 updated by RFC 8505. 331 RFC 6775 defines substitutable mechanisms for distributing prefixes 332 and context information (section 8.1 of RFC 6775), as well as for 333 Duplicate Address Detection across a route-over 6LoWPAN (section 8.2 334 of RFC 6775). RFC 8505 updates those mechanisms and the related 335 message formats. Implementations of this specification MUST either 336 support the features described in sections 8.1 and 8.2 of RFC 6775, 337 as updated by RFC 8505, or some alternative ("substitute") mechanism. 339 3.3.3. Header compression 341 Header compression as defined in RFC 6282 [RFC6282], which specifies 342 the compression format for IPv6 datagrams on top of IEEE 802.15.4, is 343 REQUIRED as the basis for IPv6 header compression on top of Bluetooth 344 LE. All headers MUST be compressed according to RFC 6282 [RFC6282] 345 encoding formats. 347 To enable efficient header compression, when the 6LBR sends a Router 348 Advertisement it MAY include a 6LoWPAN Context Option (6CO) [RFC6775] 349 matching each address prefix advertised via a Prefix Information 350 Option (PIO) [RFC4861] for use in stateless address 351 autoconfiguration. Note that 6CO is not needed for context-based 352 compression when context is pre-provisioned or provided by out-of- 353 band means. 355 The specific optimizations of RFC 7668 for header compression, which 356 exploited the star topology and ARO (note that the latter has been 357 updated by EARO as per RFC 8505), cannot be generalized in an IPv6 358 mesh over Bluetooth LE links. Still, a subset of those optimizations 359 can be applied in some cases in such a network. These cases comprise 360 link-local interactions, non-link-local packet transmissions 361 originated by a 6LN (i.e. the first hop from a 6LN), and non-link- 362 local packets intended for a 6LN that are originated or forwarded by 363 a neighbor of that 6LN (i.e. the last hop toward a 6LN). For all 364 other packet transmissions, context-based compression MAY be used. 366 When a device transmits a packet to a neighbor, the sender MUST fully 367 elide the source IID if the source IPv6 address is the link-local 368 address based on the sender's Bluetooth device address (SAC=0, 369 SAM=11). The sender also MUST fully elide the destination IPv6 370 address if it is the link-local address based on the neighbor's 371 Bluetooth device address (DAC=0, DAM=11). 373 When a 6LN transmits a packet, with a non-link-local source address 374 that the 6LN has registered with EARO in the next-hop router for the 375 indicated prefix, the source address MUST be fully elided if it is 376 the latest address that the 6LN has registered for the indicated 377 prefix (SAC=1, SAM=11). If the source non-link-local address is not 378 the latest registered by the 6LN, and the first 48 bits of the IID 379 match with the latest address registered by the 6LN, then the last 16 380 bits of the IID SHALL be carried in-line (SAC=1, SAM=10). Otherwise, 381 if the first 48 bits of the IID do not match, then the 64 bits of the 382 IID SHALL be fully carried in-line (SAC=1, SAM=01). 384 When a router transmits a packet to a neighboring 6LN, with a non- 385 link-local destination address, the router MUST fully elide the 386 destination IPv6 address if the destination address is the latest 387 registered by the 6LN with EARO for the indicated context (DAC=1, 388 DAM=11). If the destination address is a non-link-local address and 389 not the latest registered, and the first 48 bits of the IID match to 390 those of the latest registered address, then the last 16 bits of the 391 IID SHALL be carried in-line (DAC=1, DAM=10). Otherwise, if the 392 first 48 bits of the IID do not match, then the 64 bits of the IID 393 SHALL be fully carried in-line (DAC=1, DAM=01). 395 3.3.4. Unicast and multicast mapping 397 The Bluetooth LE Link Layer does not support multicast. Hence, 398 traffic is always unicast between two Bluetooth LE neighboring nodes. 399 If a node needs to send a multicast packet to several neighbors, it 400 has to replicate the packet and unicast it on each link. However, 401 this may not be energy efficient, and particular care must be taken 402 if the node is battery powered. A router (i.e., a 6LR or a 6LBR) 403 MUST keep track of neighboring multicast listeners, and it MUST NOT 404 forward multicast packets to neighbors that have not registered as 405 listeners for multicast groups to which the packets are destined. 407 4. IANA Considerations 409 There are no IANA considerations related to this document. 411 5. Security Considerations 413 The security considerations in RFC 7668 apply. 415 IPv6 mesh over Bluetooth LE links requires a routing protocol to find 416 end-to-end paths. Unfortunately, the routing protocol may generate 417 additional opportunities for threats and attacks to the network. 419 RFC 7416 [RFC7416] provides a systematic overview of threats and 420 attacks on the IPv6 Routing Protocol for Low-Power and Lossy Networks 421 (RPL), as well as countermeasures. In that document, described 422 threats and attacks comprise threats due to failures to authenticate, 423 threats due to failure to keep routing information, threats and 424 attacks on integrity, and threats and attacks on availability. 425 Reported countermeasures comprise confidentiality attack, integrity 426 attack, and availability attack countermeasures. 428 While this specification does not state the routing protocol to be 429 used in IPv6 mesh over Bluetooth LE links, the guidance of RFC 7416 430 is useful when RPL is used in such scenarios. Furthermore, such 431 guidance may partly apply for other routing protocols as well. 433 The ROVR can be derived from the Bluetooth device address. However, 434 such a ROVR can be spoofed, and therefore, any node connected to the 435 subnet and aware of a registered-address-to-ROVR mapping could 436 perform address theft and impersonation attacks. Use of Address 437 Protected Neighbor Discovery RFC 8928 [RFC8928] provides protection 438 against such attacks. 440 6. Contributors 442 Carlo Alberto Boano (Graz University of Technology) contributed to 443 the design and validation of this document. 445 7. Acknowledgements 447 The Bluetooth, Bluetooth Smart and Bluetooth Smart Ready marks are 448 registered trademarks owned by Bluetooth SIG, Inc. 450 The authors of this document are grateful to all RFC 7668 authors, 451 since this document borrows many concepts (albeit, with necessary 452 extensions) from RFC 7668. 454 The authors also thank Alain Michaud, Mark Powell, Martin Turon, 455 Bilhanan Silverajan, Rahul Jadhav, Pascal Thubert, Acee Lindem, 456 Catherine Meadows, and Dominique Barthel for their reviews and 457 comments, which helped improve the document. 459 Carles Gomez has been supported in part by the Spanish Government 460 Ministerio de Economia y Competitividad through projects 461 TEC2012-32531, TEC2016-79988-P, PID2019-106808RA-I00 and FEDER, and 462 Secretaria d'Universitats i Recerca del Departament d'Empresa i 463 Coneixement de la Generalitat de Catalunya 2017 through grant SGR 464 376. 466 8. Appendix A: Bluetooth LE connection establishment example 468 This appendix provides an example of Bluetooth LE connection 469 establishment and use of IPSP roles in an IPv6 mesh over Bluetooth LE 470 links that uses dynamic configuration. The example follows text in 471 Section 3.3.2, item 3.b). 473 The example assumes a network with one 6LBR, two 6LRs and three 6LNs, 474 as shown in Figure 3. Connectivity between the 6LNs and the 6LBR is 475 only possible via the 6LRs. 477 The following text describes the different steps as time evolves, in 478 the example. Note that other sequences of events that may lead to 479 the same final scenario are also possible. 481 At the beginning, the 6LBR starts running as an IPSP Router, whereas 482 the rest of devices are not yet initialized (Step 1). Next, the 6LRs 483 start running as IPSP Nodes, i.e., they use Bluetooth LE 484 advertisement packets to announce their presence and support of IPv6 485 capabilities (Step 2). The 6LBR (already running as an IPSP Router) 486 discovers the presence of the 6LRs and establishes one Bluetooth LE 487 connection with each 6LR (Step 3). After establishment of those link 488 layer connections (and after reception of Router Advertisements from 489 the 6LBR), Step 4, the 6LRs start operating as routers, and also 490 initiate the IPSP Router role (note: whether the IPSP Node role is 491 kept running simultaneously is an implementation decision). Then, 492 6LNs start running the IPSP Node role (Step 5). Finally, the 6LRs 493 discover presence of the 6LNs and establish connections with the 494 latter (Step 6). 496 Step 1 497 ****** 498 6LBR 499 (IPSP: Router) 501 6LR 6LR 502 (not initialized) (not initialized) 504 6LN 6LN 6LN 505 (not initialized) (not initialized) (not initialized) 507 Step 2 508 ****** 509 6LBR 510 (IPSP: Router) 512 6LR 6LR 513 (IPSP: Node) (IPSP: Node) 515 6LN 6LN 6LN 516 (not initialized) (not initialized) (not initialized) 518 Step 3 519 ****** 521 6LBR 522 (IPSP: Router) 523 Bluetooth LE connection --> / \ 524 / \ 525 6LR 6LR 526 (IPSP: Node) (IPSP: Node) 528 6LN 6LN 6LN 529 (not initialized) (not initialized) (not initialized) 531 Step 4 532 ****** 534 6LBR 535 (IPSP: Router) 536 / \ 537 / \ 538 6LR 6LR 539 (IPSP: Router) (IPSP: Router) 541 6LN 6LN 6LN 542 (not initialized) (not initialized) (not initialized) 544 Step 5 545 ****** 547 6LBR 548 (IPSP: Router) 549 / \ 550 / \ 551 6LR 6LR 552 (IPSP: Router) (IPSP: Router) 554 6LN 6LN 6LN 555 (IPSP: Node) (IPSP: Node) (IPSP: Node) 557 Step 6 558 ****** 560 6LBR 561 (IPSP: Router) 562 / \ 563 / \ 564 6LR 6LR 565 (IPSP: Router) (IPSP: Router) 566 / \ / \ 567 / \ / \ 568 / \ / \ 569 6LN 6LN 6LN 570 (IPSP: Node) (IPSP: Node) (IPSP: Node) 572 Figure 3: An example of connection establishment and use of IPSP 573 roles in an IPv6 mesh over Bluetooth LE links. 575 9. Appendix B: Node joining procedure 577 This appendix provides a diagram that illustrates the node joining 578 procedure. First of all, the joining node advertises its presence in 579 order to allow establishing Bluetooth LE connections with neighbors 580 that already belong to a network. The latter typically run as a 6LR 581 or as a 6LBR. After Bluetooth LE connection establishment, the 582 joining node starts acting as a 6LN. 584 Figure 4 shows the sequence of messages that are exchanged by the 6LN 585 and a neighboring 6LR that already belongs to the network, after the 586 establishment of a Bluetooth LE connection between both devices. 587 Initially, the 6LN sends an RS message (1). Then, the 6LR replies 588 with an RA, which includes the PIO (2). After discovering the non- 589 link-local prefix in use in the network, the 6LN creates its non- 590 link-local address, registers that address with EARO (3) in the 6LR, 591 and multihop DAD is performed (4). The next step is the transmission 592 of the NA message sent by the 6LR in response to the NS previously 593 sent by the 6LN (5). If the non-link-local address of the 6LN has 594 been successfully validated, the 6LN can operate as a member of the 595 network it has joined. 597 (1) 6LN ----(RS)-------> 6LR 598 (2) 6LN <---(RA-PIO)---- 6LR 599 (3) 6LN ----(NS-EARO)--> 6LR 600 (4) [Multihop DAD procedure] 601 (5) 6LN <---(NA)-------- 6LR 603 Figure 4: Message exchange diagram for a joining node 605 10. References 607 10.1. Normative References 609 [BTCorev4.2] 610 Bluetooth Special Interest Group, "Bluetooth Core 611 Specification Version 4.2", December 2014, 612 . 615 [IPSP] Bluetooth Special Interest Group, "Bluetooth Internet 616 Protocol Support Profile Specification Version 1.0.0", 617 December 2014, . 620 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 621 Requirement Levels", BCP 14, RFC 2119, 622 DOI 10.17487/RFC2119, March 1997, 623 . 625 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 626 Architecture", RFC 4291, DOI 10.17487/RFC4291, February 627 2006, . 629 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 630 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 631 DOI 10.17487/RFC4861, September 2007, 632 . 634 [RFC6282] Hui, J., Ed. and P. Thubert, "Compression Format for IPv6 635 Datagrams over IEEE 802.15.4-Based Networks", RFC 6282, 636 DOI 10.17487/RFC6282, September 2011, 637 . 639 [RFC6775] Shelby, Z., Ed., Chakrabarti, S., Nordmark, E., and C. 640 Bormann, "Neighbor Discovery Optimization for IPv6 over 641 Low-Power Wireless Personal Area Networks (6LoWPANs)", 642 RFC 6775, DOI 10.17487/RFC6775, November 2012, 643 . 645 [RFC7668] Nieminen, J., Savolainen, T., Isomaki, M., Patil, B., 646 Shelby, Z., and C. Gomez, "IPv6 over BLUETOOTH(R) Low 647 Energy", RFC 7668, DOI 10.17487/RFC7668, October 2015, 648 . 650 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 651 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 652 May 2017, . 654 [RFC8505] Thubert, P., Ed., Nordmark, E., Chakrabarti, S., and C. 655 Perkins, "Registration Extensions for IPv6 over Low-Power 656 Wireless Personal Area Network (6LoWPAN) Neighbor 657 Discovery", RFC 8505, DOI 10.17487/RFC8505, November 2018, 658 . 660 [RFC8928] Thubert, P., Ed., Sarikaya, B., Sethi, M., and R. Struik, 661 "Address-Protected Neighbor Discovery for Low-Power and 662 Lossy Networks", RFC 8928, DOI 10.17487/RFC8928, November 663 2020, . 665 10.2. Informative References 667 [BTCorev4.1] 668 Bluetooth Special Interest Group, "Bluetooth Core 669 Specification Version 4.1", December 2013, 670 . 673 [RFC4903] Thaler, D., "Multi-Link Subnet Issues", RFC 4903, 674 DOI 10.17487/RFC4903, June 2007, 675 . 677 [RFC7416] Tsao, T., Alexander, R., Dohler, M., Daza, V., Lozano, A., 678 and M. Richardson, Ed., "A Security Threat Analysis for 679 the Routing Protocol for Low-Power and Lossy Networks 680 (RPLs)", RFC 7416, DOI 10.17487/RFC7416, January 2015, 681 . 683 Authors' Addresses 685 Carles Gomez 686 Universitat Politecnica de Catalunya 687 C/Esteve Terradas, 7 688 Castelldefels 08860 689 Spain 691 Email: carlesgo@entel.upc.edu 693 Seyed Mahdi Darroudi 694 Universitat Politecnica de Catalunya 695 C/Esteve Terradas, 7 696 Castelldefels 08860 697 Spain 699 Email: sm.darroudi@entel.upc.edu 701 Teemu Savolainen 702 DarkMatter LLC 704 Email: teemu.savolainen@darkmatter.ae 706 Michael Spoerk 707 Graz University of Technology 708 Inffeldgasse 16/I 709 Graz 8010 710 Austria 712 Email: michael.spoerk@tugraz.at