idnits 2.17.1 draft-ietf-6lo-blemesh-06.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 date (September 28, 2019) is 1673 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) == Missing Reference: 'RFC 7416' is mentioned on line 396, but not defined == Unused Reference: 'RFC7668' is defined on line 619, but no explicit reference was found in the text == Unused Reference: 'RFC7416' is defined on line 648, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'IPSP' == Outdated reference: A later version (-23) exists of draft-ietf-6lo-ap-nd-12 Summary: 0 errors (**), 0 flaws (~~), 5 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: March 31, 2020 T. Savolainen 6 DarkMatter 7 M. Spoerk 8 Graz University of Technology 9 September 28, 2019 11 IPv6 Mesh over BLUETOOTH(R) Low Energy using IPSP 12 draft-ietf-6lo-blemesh-06 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 March 31, 2020. 42 Copyright Notice 44 Copyright (c) 2019 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 . . . . . . . . . . . . . . . . . 7 69 3.3.4. Unicast and multicast mapping . . . . . . . . . . . . 8 70 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 71 5. Security Considerations . . . . . . . . . . . . . . . . . . . 9 72 6. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 9 73 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 74 8. Appendix A: Bluetooth LE connection establishment example . . 10 75 9. Appendix B: Node joining procedure . . . . . . . . . . . . . 13 76 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 77 10.1. Normative References . . . . . . . . . . . . . . . . . . 13 78 10.2. Informative References . . . . . . . . . . . . . . . . . 14 79 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 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, respectively. Bluetooth 4.0 only supports Bluetooth LE 94 networks that follow the star topology. In consequence, RFC 7668 was 95 specifically developed and optimized for that type of network 96 topology. However, the functionality described in RFC 7668 is not 97 sufficient and would fail to enable an IPv6 mesh over Bluetooth LE 98 links. This document specifies mechanisms that are needed to enable 99 IPv6 mesh over Bluetooth LE links. This document does not specify 100 the routing protocol to be used in an IPv6 mesh over Bluetooth LE 101 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 RFC 2119 [RFC2119]. 109 The terms 6LoWPAN Node (6LN), 6LoWPAN Router (6LR) and 6LoWPAN Border 110 Router (6LBR) are defined as in [RFC6775], with an addition that 111 Bluetooth LE central and Bluetooth LE peripheral (see Section 2) can 112 both be adopted by a 6LN, a 6LR or a 6LBR. 114 2. Bluetooth LE Networks and the IPSP 116 Bluetooth LE defines two Generic Access Profile (GAP) roles of 117 relevance herein: the Bluetooth LE central role and the Bluetooth LE 118 peripheral role. A device in the central role, which is called 119 central from now on, has traditionally been able to manage multiple 120 simultaneous connections with a number of devices in the peripheral 121 role, called peripherals hereinafter. Bluetooth 4.1 (now deprecated) 122 introduced the possibility for a peripheral to be connected to more 123 than one central simultaneously, therefore allowing extended 124 topologies beyond the star topology for a Bluetooth LE network. In 125 addition, a device may simultaneously be a central in a set of link 126 layer connections, as well as a peripheral in others. On the other 127 hand, the IPSP enables discovery of IP-enabled devices and the 128 establishment of a link layer connection for transporting IPv6 129 packets. The IPSP defines the Node and Router roles for devices that 130 consume/originate IPv6 packets and for devices that can route IPv6 131 packets, respectively. Consistently with Bluetooth 4.1 and 132 subsequent Bluetooth versions (e.g. Bluetooth 4.2 [BTCorev4.2] or 133 subsequent), a device may implement both roles simultaneously. 135 This document assumes a mesh network composed of Bluetooth LE links, 136 where link layer connections are established between neighboring 137 IPv6-enabled devices (see Section 3.3.2, item 3.b)). The IPv6 138 forwarding devices of the mesh have to implement both Node and Router 139 roles, while simpler leaf-only nodes can implement only the Node 140 role. In an IPv6 mesh over Bluetooth LE links, a node is a neighbor 141 of another node, and vice versa, if a link layer connection has been 142 established between both by using the IPSP functionality for 143 discovery and link layer connection establishment for IPv6 packet 144 transport. 146 3. Specification of IPv6 mesh over Bluetooth LE links 148 3.1. Protocol stack 150 Figure 1 illustrates the protocol stack for IPv6 mesh over Bluetooth 151 LE links. There are two main differences with the IPv6 over 152 Bluetooth LE stack in RFC 7668: a) the adaptation layer below IPv6 153 (labelled as "6Lo for IPv6 mesh over Bluetooth LE") is now adapted 154 for IPv6 mesh over Bluetooth LE links, and b) the protocol stack for 155 IPv6 mesh over Bluetooth LE links includes IPv6 routing 156 functionality. 158 +------------------------------------+ 159 | Application | 160 +---------+ +------------------------------------+ 161 | IPSS | | UDP/TCP/other | 162 +---------+ +------------------------------------+ 163 | GATT | | IPv6 |routing| | 164 +---------+ +------------------------------------+ 165 | ATT | | 6Lo for IPv6 mesh over Bluetooh LE | 166 +---------+--+------------------------------------+ 167 | Bluetooth LE L2CAP | 168 - - +-------------------------------------------------+- - - HCI 169 | Bluetooth LE Link Layer | 170 +-------------------------------------------------+ 171 | Bluetooth LE Physical | 172 +-------------------------------------------------+ 174 Figure 1: Protocol stack for IPv6 mesh over Bluetooth LE links. 176 Bluetooth 4.2 defines a default MTU for Bluetooth LE of 251 bytes. 177 Excluding the L2CAP header of 4 bytes, a protocol data unit (PDU) 178 size of 247 bytes is available for the layer above L2CAP. (Note: 179 earlier Bluetooth LE versions offered a maximum amount of 23 bytes 180 for the layer atop L2CAP.) The L2CAP provides a fragmentation and 181 reassembly solution for transmitting or receiving larger PDUs. At 182 each link, the IPSP defines means for negotiating a link-layer 183 connection that provides an MTU of 1280 octets or higher for the IPv6 184 layer [IPSP]. The link-layer MTU is negotiated separately for each 185 direction. Implementations that require an equal link-layer MTU for 186 the two directions SHALL use the smallest of the possibly different 187 MTU values. 189 Note that this specification allows using different MTUs in different 190 links. If an implementation requires use of the same MTU on every 191 one of its links, and a new node with a smaller MTU is added to the 192 network, a renegotiation of one or more links can occur. In the 193 worst case, the renegotiations could cascade network-wide. In that 194 case, implementers need to assess the impact of such phenomenon. 196 Similarly to RFC 7668, fragmentation functionality from 6LoWPAN 197 standards is not used for IPv6 mesh over Bluetooth LE links. 198 Bluetooth LE's fragmentation support provided by L2CAP is used when 199 necessary. 201 3.2. Subnet model 203 For IPv6 mesh over Bluetooth LE links, a multilink model has been 204 chosen, as further illustrated in Figure 2. As IPv6 over Bluetooth 205 LE is intended for constrained nodes, and for Internet of Things use 206 cases and environments, the complexity of implementing a separate 207 subnet on each peripheral-central link and routing between the 208 subnets appears to be excessive. In this specification, the benefits 209 of treating the collection of point-to-point links between a central 210 and its connected peripherals as a single multilink subnet rather 211 than a multiplicity of separate subnets are considered to outweigh 212 the multilink model's drawbacks as described in [RFC4903]. 214 / 215 .--------------------------------. / 216 / 6LR 6LN 6LN \ / 217 / \ \ \ \ / 218 | \ \ \ | / 219 | 6LN ----- 6LR --------- 6LR ------ 6LBR ----- | Internet 220 | <--Link--> <---Link--->/<--Link->/ | | 221 \ / / / \ 222 \ 6LN ---- 6LR ----- 6LR / \ 223 '--------------------------------' \ 224 \ 226 <------------ Subnet -----------------><---- IPv6 connection --> 227 to the Internet 229 Figure 2: Example of an IPv6 mesh over a Bluetooth LE network 230 connected to the Internet 232 One or more 6LBRs are connected to the Internet. 6LNs are connected 233 to the network through a 6LR or a 6LBR. A prefix is used on the 234 whole subnet. 236 IPv6 mesh over Bluetooth LE links MUST follow a route-over approach. 237 This document does not specify the routing protocol to be used in an 238 IPv6 mesh over Bluetooth LE links. 240 3.3. Link model 242 3.3.1. Stateless address autoconfiguration 244 6LN, 6LR and 6LBR IPv6 addresses in an IPv6 mesh over Bluetooth LE 245 links are configured as per section 3.2.2 of RFC 7668. 247 Multihop DAD functionality as defined in section 8.2 of RFC 6775 and 248 updated by RFC 8505, or some substitute mechanism (see section 249 3.3.2), MUST be supported. 251 3.3.2. Neighbor Discovery 253 'Neighbor Discovery Optimization for IPv6 over Low-Power Wireless 254 Personal Area Networks (6LoWPANs)' [RFC6775], subsequently updated by 255 'Registration Extensions for IPv6 over Low-Power Wireless Personal 256 Area Network (6LoWPAN) Neighbor Discovery' [RFC8505], describes the 257 neighbor discovery functionality adapted for use in several 6LoWPAN 258 topologies, including the mesh topology. The route-over 259 functionality of RFC 6775 and RFC 8505 MUST be supported. 261 The following aspects of the Neighbor Discovery optimizations for 262 6LoWPAN [RFC6775],[RFC8505] are applicable to Bluetooth LE 6LNs: 264 1. A Bluetooth LE host MUST register its non-link-local addresses 265 with its routers by sending a Neighbor Solicitation (NS) message with 266 the Extended Address Registration Option (EARO) and process the 267 Neighbor Advertisement (NA) accordingly. The NS with the EARO option 268 MUST be sent irrespective of the method used to generate the IID. 269 The EARO option includes a Registration Ownership Verifier (ROVR) 270 field [RFC8505]. In the case of Bluetooth LE, by default the ROVR 271 field is filled with the 48-bit device address used by the Bluetooth 272 LE node converted into 64-bit Modified EUI-64 format [RFC4291]. 273 Optionally, a cryptographic ID (see [I-D.ietf-6lo-ap-nd] MAY be 274 placed in the ROVR field. If a cryptographic ID is used, address 275 registration and multihop DAD formats and procedures defined in 276 [I-D.ietf-6lo-ap-nd] MUST be used, unless an alternative mechanism 277 offering equivalent protection is used. As per RFC 8505, a 6LN MUST 278 NOT register its link-local address. 280 If the 6LN registers for a same compression context multiple 281 addresses that are not based on Bluetooth device address, the header 282 compression efficiency will decrease. 284 2. For sending Router Solicitations and processing Router 285 Advertisements the Bluetooth LE hosts MUST, respectively, follow 286 Sections 5.3 and 5.4 of [RFC6775], and Section 5.6 of [RFC8505]. 288 3. The router behavior for 6LRs and 6LBRs is described in Section 6 289 of RFC 6775, and updated by RFC 8505. However, as per this 290 specification: a) Routers SHALL NOT use multicast NSs to discover 291 other routers' link layer addresses. b) As per section 6.2 of RFC 292 6775, in a dynamic configuration scenario, a 6LR comes up as a non- 293 router and waits to receive a Router Advertisement for configuring 294 its own interface address first, before setting its interfaces to be 295 advertising interfaces and turning into a router. In order to 296 support such operation in an IPv6 mesh over Bluetooth LE links, a 6LR 297 first uses the IPSP Node role only. Once the 6LR has established a 298 connection with another node previously running as a router, and 299 receives a Router Advertisement from that router, the 6LR configures 300 its own interface address, it turns into a router, and it runs as an 301 IPSP Router. A 6LBR uses the IPSP Router role since the 6LBR is 302 initialized. See an example in the Appendix. 304 4. Border router behavior is described in Section 7 of RFC 6775, and 305 updated by RFC 8505. 307 RFC 6775 defines substitutable mechanisms for distributing prefixes 308 and context information (section 8.1 of RFC 6775), as well as for 309 Duplicate Address Detection across a route-over 6LoWPAN (section 8.2 310 of RFC 6775). RFC 8505 updates those mechanisms and the related 311 message formats. Implementations of this specification MUST support 312 the features described in sections 8.1 and 8.2 of RFC 6775, as 313 updated by RFC 8505, unless some alternative ("substitute") from some 314 other specification is supported by the implementation. 316 3.3.3. Header compression 318 Header compression as defined in RFC 6282 [RFC6282], which specifies 319 the compression format for IPv6 datagrams on top of IEEE 802.15.4, is 320 REQUIRED as the basis for IPv6 header compression on top of Bluetooth 321 LE. All headers MUST be compressed according to RFC 6282 [RFC6282] 322 encoding formats. 324 To enable efficient header compression, when the 6LBR sends a Router 325 Advertisement it MAY include a 6LoWPAN Context Option (6CO) [RFC6775] 326 matching each address prefix advertised via a Prefix Information 327 Option (PIO) [RFC4861] for use in stateless address 328 autoconfiguration. Note that 6CO is not needed for context-based 329 compression when a single prefix is used in the network. 331 The specific optimizations of RFC 7668 for header compression, which 332 exploited the star topology and ARO (note that the latter has been 333 updated by EARO as per RFC 8505), cannot be generalized in an IPv6 334 mesh over Bluetooth LE links. Still, a subset of those optimizations 335 can be applied in some cases in such a network. These cases comprise 336 link-local interactions, non-link-local packet transmissions 337 originated and performed by a 6LN, and non-link-local packets 338 intended for a 6LN that are originated or forwarded by a neighbor of 339 that 6LN. For the rest of packet transmissions, context- based 340 compression MAY be used. 342 When a device transmits a packet to a neighbor, the sender MUST fully 343 elide the source IID if the source IPv6 address is the link-local 344 address based on the sender's Bluetooth device address (SAC=0, 345 SAM=11). The sender also MUST fully elide the destination IPv6 346 address if it is the link-local address based on the neighbor's 347 Bluetooth device address (DAC=0, DAM=11). 349 A 6LN SHOULD register its non-link-local address with EARO in the 350 next-hop router. Note that in some cases (e.g. very short-lived 351 connections) it may not be worthwhile for a 6LN to send an NS with 352 EARO for registering its address. When a 6LN transmits a packet, 353 with a non-link-local source address that the 6LN has registered with 354 EARO in the next-hop router for the indicated prefix, the source 355 address MUST be fully elided if it is the latest address that the 6LN 356 has registered for the indicated prefix (SAC=1, SAM=11). If the 357 source non-link-local address is not the latest registered by the 358 6LN, then the 64 bits of the IID SHALL be fully carried in-line 359 (SAC=1, SAM=01) or if the first 48 bits of the IID match with the 360 latest address registered by the 6LN, then the last 16 bits of the 361 IID SHALL be carried in-line (SAC=1, SAM=10). 363 When a router transmits a packet to a neighboring 6LN, with a non- 364 link-local destination address, the router MUST fully elide the 365 destination IPv6 address if the destination address is the latest 366 registered by the 6LN with EARO for the indicated context (DAC=1, 367 DAM=11). If the destination address is a non-link-local address and 368 not the latest registered, then the 6LN MUST either include the IID 369 part fully in-line (DAM=01) or, if the first 48 bits of the IID match 370 to the latest registered address, then elide those 48 bits (DAM=10). 372 3.3.4. Unicast and multicast mapping 374 The Bluetooth LE Link Layer does not support multicast. Hence, 375 traffic is always unicast between two Bluetooth LE neighboring nodes. 376 If a node needs to send a multicast packet to several neighbors, it 377 has to replicate the packet and unicast it on each link. However, 378 this may not be energy efficient, and particular care must be taken 379 if the node is battery powered. A router (i.e. a 6LR or a 6LBR) MUST 380 keep track of neighboring multicast listeners, and it MUST NOT 381 forward multicast packets to neighbors that have not registered as 382 listeners for multicast groups the packets belong to. 384 4. IANA Considerations 386 There are no IANA considerations related to this document. 388 5. Security Considerations 390 The security considerations in RFC 7668 apply. 392 IPv6 mesh over Bluetooth LE links requires a routing protocol to find 393 end-to-end paths. Unfortunately, the routing protocol may generate 394 additional opportunities for threats and attacks to the network. 396 RFC 7416 [RFC 7416] provides a systematic overview of threats and 397 attacks on the IPv6 Routing Protocol for Low-Power and Lossy Networks 398 (RPL), as well as countermeasures. In that document, described 399 threats and attacks comprise threats due to failures to authenticate, 400 threats due to failure to keep routing information, threats and 401 attacks on integrity, and threats and attacks on availability. 402 Reported countermeasures comprise confidentiality attack, integrity 403 attack, and availability attack countermeasures. 405 While this specification does not state the routing protocol to be 406 used in IPv6 mesh over Bluetooth LE links, the guidance of RFC 7416 407 is useful when RPL is used in such scenarios. Furthermore, such 408 guidance may partly apply for other routing protocols as well. 410 The ROVR can be derived from the Bluetooth device address. However, 411 such a ROVR can be spoofed, and therefore, any node connected to the 412 subnet and aware of a registered-address-to-ROVR mapping could 413 perform address theft and impersonation attacks. Use of Address 414 Protected Neighbor Discovery [I-D.ietf-6lo-ap-nd] provides protection 415 against such attacks. 417 6. Contributors 419 Carlo Alberto Boano (Graz University of Technology) contributed to 420 the design and validation of this document. 422 7. Acknowledgements 424 The Bluetooth, Bluetooth Smart and Bluetooth Smart Ready marks are 425 registered trademarks owned by Bluetooth SIG, Inc. 427 The authors of this document are grateful to all RFC 7668 authors, 428 since this document borrows many concepts (albeit, with necessary 429 extensions) from RFC 7668. 431 The authors also thank Alain Michaud, Mark Powell, Martin Turon, 432 Bilhanan Silverajan, Rahul Jadhav and Pascal Thubert for their 433 comments, which helped improve the document. 435 Carles Gomez has been supported in part by the Spanish Government 436 Ministerio de Economia y Competitividad through projects 437 TEC2012-32531, TEC2016-79988-P and FEDER. 439 8. Appendix A: Bluetooth LE connection establishment example 441 This appendix provides an example of Bluetooth LE connection 442 establishment and use of IPSP roles in an IPv6 mesh over Bluetooth LE 443 links that uses dynamic configuration. The example follows text in 444 Section 3.3.2, item 3.b). 446 The example assumes a network with one 6LBR, two 6LRs and three 6LNs, 447 as shown in Figure 3. Connectivity between the 6LNs and the 6LBR is 448 only possible via the 6LRs. 450 The following text describes the different steps as time evolves, in 451 the example. Note that other sequences of events that may lead to 452 the same final scenario are also possible. 454 At the beginning, the 6LBR starts running as an IPSP Router, whereas 455 the rest of devices are not yet initialized (Step 1). Next, the 6LRs 456 start running as IPSP Nodes, i.e., they use Bluetooth LE 457 advertisement packets to announce their presence and support of IPv6 458 capabilities (Step 2). The 6LBR (already running as an IPSP Router) 459 discovers the presence of the 6LRs and establishes one Bluetooth LE 460 connection with each 6LR (Step 3). After establishment of those link 461 layer connections (and after reception of Router Advertisements from 462 the 6LBR), Step 4, the 6LRs start operating as routers, and also 463 initiate the IPSP Router role (note: whether the IPSP Node role is 464 kept running simultaneously is an implementation decision). Then, 465 6LNs start running the IPSP Node role (Step 5). Finally, the 6LRs 466 discover presence of the 6LNs and establish connections with the 467 latter (Step 6). 469 Step 1 470 ****** 471 6LBR 472 (IPSP: Router) 474 6LR 6LR 475 (not initialized) (not initialized) 477 6LN 6LN 6LN 478 (not initialized) (not initialized) (not initialized) 480 Step 2 481 ****** 482 6LBR 483 (IPSP: Router) 485 6LR 6LR 486 (IPSP: Node) (IPSP: Node) 488 6LN 6LN 6LN 489 (not initialized) (not initialized) (not initialized) 491 Step 3 492 ****** 494 6LBR 495 (IPSP: Router) 496 Bluetooth LE connection --> / \ 497 / \ 498 6LR 6LR 499 (IPSP: Node) (IPSP: Node) 501 6LN 6LN 6LN 502 (not initialized) (not initialized) (not initialized) 504 Step 4 505 ****** 507 6LBR 508 (IPSP: Router) 509 / \ 511 / \ 512 6LR 6LR 513 (IPSP: Router) (IPSP: Router) 515 6LN 6LN 6LN 516 (not initialized) (not initialized) (not initialized) 518 Step 5 519 ****** 521 6LBR 522 (IPSP: Router) 523 / \ 524 / \ 525 6LR 6LR 526 (IPSP: Router) (IPSP: Router) 528 6LN 6LN 6LN 529 (IPSP: Node) (IPSP: Node) (IPSP: Node) 531 Step 6 532 ****** 534 6LBR 535 (IPSP: Router) 536 / \ 537 / \ 538 6LR 6LR 539 (IPSP: Router) (IPSP: Router) 540 / \ / \ 541 / \ / \ 542 / \ / \ 543 6LN 6LN 6LN 544 (IPSP: Node) (IPSP: Node) (IPSP: Node) 546 Figure 3: An example of connection establishment and use of IPSP 547 roles in an IPv6 mesh over Bluetooth LE links. 549 9. Appendix B: Node joining procedure 551 This appendix provides a diagram that illustrates the node joining 552 procedure. First of all, the joining node advertises its presence in 553 order to allow establishing Bluetooth LE connections with neighbors 554 that already belong to a network. The latter typically run as a 6LR 555 or as a 6LBR. After Bluetooth LE connection establishment, the 556 joining node starts acting as a 6LN. 558 Figure 4 shows the sequence of messages that are exchanged by the 6LN 559 and a neighboring 6LR that already belongs to the network, after the 560 establishment of a Bluetooth LE connection between both devices. 561 Initially, the 6LN sends an RS message (1). Then, the 6LR replies 562 with an RA, which includes the PIO (2). After discovering the non- 563 link-local prefix in use in the network, the 6LN creates its non- 564 link-local address, registers that address with EARO (3) in the 6LR, 565 and multihop DAD is performed (4). The next step is the transmission 566 of the NA message sent by the 6LR in response to the NS previously 567 sent by the 6LN (5). If the non-link-local address of the 6LN has 568 been successfully validated, the 6LN can operate as a member of the 569 network it has joined. 571 (1) 6LN ----(RS)-------> 6LR 572 (2) 6LN <---(RA-PIO)---- 6LR 573 (3) 6LN ----(NS-EARO)--> 6LR 574 (4) [Multihop DAD procedure] 575 (5) 6LN <---(NA)-------- 6LR 577 Figure 4: Message exchange diagram for a joining node 579 10. References 581 10.1. Normative References 583 [BTCorev4.2] 584 Bluetooth Special Interest Group, "Bluetooth Core 585 Specification Version 4.2", December 2014, 586 . 589 [IPSP] Bluetooth Special Interest Group, "Bluetooth Internet 590 Protocol Support Profile Specification Version 1.0.0", 591 December 2014, . 594 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 595 Requirement Levels", BCP 14, RFC 2119, 596 DOI 10.17487/RFC2119, March 1997, 597 . 599 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 600 Architecture", RFC 4291, DOI 10.17487/RFC4291, February 601 2006, . 603 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 604 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 605 DOI 10.17487/RFC4861, September 2007, 606 . 608 [RFC6282] Hui, J., Ed. and P. Thubert, "Compression Format for IPv6 609 Datagrams over IEEE 802.15.4-Based Networks", RFC 6282, 610 DOI 10.17487/RFC6282, September 2011, 611 . 613 [RFC6775] Shelby, Z., Ed., Chakrabarti, S., Nordmark, E., and C. 614 Bormann, "Neighbor Discovery Optimization for IPv6 over 615 Low-Power Wireless Personal Area Networks (6LoWPANs)", 616 RFC 6775, DOI 10.17487/RFC6775, November 2012, 617 . 619 [RFC7668] Nieminen, J., Savolainen, T., Isomaki, M., Patil, B., 620 Shelby, Z., and C. Gomez, "IPv6 over BLUETOOTH(R) Low 621 Energy", RFC 7668, DOI 10.17487/RFC7668, October 2015, 622 . 624 [RFC8505] Thubert, P., Ed., Nordmark, E., Chakrabarti, S., and C. 625 Perkins, "Registration Extensions for IPv6 over Low-Power 626 Wireless Personal Area Network (6LoWPAN) Neighbor 627 Discovery", RFC 8505, DOI 10.17487/RFC8505, November 2018, 628 . 630 10.2. Informative References 632 [BTCorev4.1] 633 Bluetooth Special Interest Group, "Bluetooth Core 634 Specification Version 4.1", December 2013, 635 . 638 [I-D.ietf-6lo-ap-nd] 639 Thubert, P., Sarikaya, B., Sethi, M., and R. Struik, 640 "Address Protected Neighbor Discovery for Low-power and 641 Lossy Networks", draft-ietf-6lo-ap-nd-12 (work in 642 progress), April 2019. 644 [RFC4903] Thaler, D., "Multi-Link Subnet Issues", RFC 4903, 645 DOI 10.17487/RFC4903, June 2007, 646 . 648 [RFC7416] Tsao, T., Alexander, R., Dohler, M., Daza, V., Lozano, A., 649 and M. Richardson, Ed., "A Security Threat Analysis for 650 the Routing Protocol for Low-Power and Lossy Networks 651 (RPLs)", RFC 7416, DOI 10.17487/RFC7416, January 2015, 652 . 654 Authors' Addresses 656 Carles Gomez 657 Universitat Politecnica de Catalunya 658 C/Esteve Terradas, 7 659 Castelldefels 08860 660 Spain 662 Email: carlesgo@entel.upc.edu 664 Seyed Mahdi Darroudi 665 Universitat Politecnica de Catalunya 666 C/Esteve Terradas, 7 667 Castelldefels 08860 668 Spain 670 Email: sm.darroudi@entel.upc.edu 672 Teemu Savolainen 673 DarkMatter LLC 675 Email: teemu.savolainen@darkmatter.ae 676 Michael Spoerk 677 Graz University of Technology 678 Inffeldgasse 16/I 679 Graz 8010 680 Austria 682 Email: michael.spoerk@tugraz.at