idnits 2.17.1 draft-ietf-6lo-blemesh-05.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 (March 9, 2019) is 1869 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 393, but not defined == Unused Reference: 'RFC7668' is defined on line 586, but no explicit reference was found in the text == Unused Reference: 'RFC7416' is defined on line 615, 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-11 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: September 10, 2019 T. Savolainen 6 DarkMatter 7 M. Spoerk 8 Graz University of Technology 9 March 9, 2019 11 IPv6 Mesh over BLUETOOTH(R) Low Energy using IPSP 12 draft-ietf-6lo-blemesh-05 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 September 10, 2019. 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 . . . . . . . . . . . . . . . . . . . . . . . . . . 10 75 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 76 9.1. Normative References . . . . . . . . . . . . . . . . . . 13 77 9.2. Informative References . . . . . . . . . . . . . . . . . 14 78 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 80 1. Introduction 82 Bluetooth Low Energy (hereinafter, Bluetooth LE) was first introduced 83 in the Bluetooth 4.0 specification. Bluetooth LE (which has been 84 marketed as Bluetooth Smart) is a low-power wireless technology 85 designed for short-range control and monitoring applications. 86 Bluetooth LE is currently implemented in a wide range of consumer 87 electronics devices, such as smartphones and wearable devices. Given 88 the high potential of this technology for the Internet of Things, the 89 Bluetooth Special Interest Group (Bluetooth SIG) and the IETF have 90 produced specifications in order to enable IPv6 over Bluetooth LE, 91 such as the Internet Protocol Support Profile (IPSP) [IPSP], and RFC 92 7668, respectively. Bluetooth 4.0 only supports Bluetooth LE 93 networks that follow the star topology. In consequence, RFC 7668 was 94 specifically developed and optimized for that type of network 95 topology. However, the functionality described in RFC 7668 is not 96 sufficient and would fail to enable an IPv6 mesh over Bluetooth LE 97 links. This document specifies mechanisms that are needed to enable 98 IPv6 mesh over Bluetooth LE links. This document does not specify 99 the routing protocol to be used in an IPv6 mesh over Bluetooth LE 100 links. 102 1.1. Terminology and Requirements Language 104 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 105 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 106 document are to be interpreted as described in RFC 2119 [RFC2119]. 108 The terms 6LoWPAN Node (6LN), 6LoWPAN Router (6LR) and 6LoWPAN Border 109 Router (6LBR) are defined as in [RFC6775], with an addition that 110 Bluetooth LE central and Bluetooth LE peripheral (see Section 2) can 111 both be adopted by a 6LN, a 6LR or a 6LBR. 113 2. Bluetooth LE Networks and the IPSP 115 Bluetooth LE defines two Generic Access Profile (GAP) roles of 116 relevance herein: the Bluetooth LE central role and the Bluetooth LE 117 peripheral role. A device in the central role, which is called 118 central from now on, has traditionally been able to manage multiple 119 simultaneous connections with a number of devices in the peripheral 120 role, called peripherals hereinafter. Bluetooth 4.1 (now deprecated) 121 introduced the possibility for a peripheral to be connected to more 122 than one central simultaneously, therefore allowing extended 123 topologies beyond the star topology for a Bluetooth LE network. In 124 addition, a device may simultaneously be a central in a set of link 125 layer connections, as well as a peripheral in others. On the other 126 hand, the IPSP enables discovery of IP-enabled devices and the 127 establishment of a link layer connection for transporting IPv6 128 packets. The IPSP defines the Node and Router roles for devices that 129 consume/originate IPv6 packets and for devices that can route IPv6 130 packets, respectively. Consistently with Bluetooth 4.1 and 131 subsequent Bluetooth versions (e.g. Bluetooth 4.2 [BTCorev4.2] or 132 subsequent), a device may implement both roles simultaneously. 134 This document assumes a mesh network composed of Bluetooth LE links, 135 where link layer connections are established between neighboring 136 IPv6-enabled devices (see Section 3.3.2, item 3.b)). The IPv6 137 forwarding devices of the mesh have to implement both Node and Router 138 roles, while simpler leaf-only nodes can implement only the Node 139 role. In an IPv6 mesh over Bluetooth LE links, a node is a neighbor 140 of another node, and vice versa, if a link layer connection has been 141 established between both by using the IPSP functionality for 142 discovery and link layer connection establishment for IPv6 packet 143 transport. 145 3. Specification of IPv6 mesh over Bluetooth LE links 147 3.1. Protocol stack 149 Figure 1 illustrates the protocol stack for IPv6 mesh over Bluetooth 150 LE links. There are two main differences with the IPv6 over 151 Bluetooth LE stack in RFC 7668: a) the adaptation layer below IPv6 152 (labelled as "6Lo for IPv6 mesh over Bluetooth LE") is now adapted 153 for IPv6 mesh over Bluetooth LE links, and b) the protocol stack for 154 IPv6 mesh over Bluetooth LE links includes IPv6 routing 155 functionality. 157 +------------------------------------+ 158 | Application | 159 +---------+ +------------------------------------+ 160 | IPSS | | UDP/TCP/other | 161 +---------+ +------------------------------------+ 162 | GATT | | IPv6 |routing| | 163 +---------+ +------------------------------------+ 164 | ATT | | 6Lo for IPv6 mesh over Bluetooh LE | 165 +---------+--+------------------------------------+ 166 | Bluetooth LE L2CAP | 167 - - +-------------------------------------------------+- - - HCI 168 | Bluetooth LE Link Layer | 169 +-------------------------------------------------+ 170 | Bluetooth LE Physical | 171 +-------------------------------------------------+ 173 Figure 1: Protocol stack for IPv6 mesh over Bluetooth LE links. 175 Bluetooth 4.2 defines a default MTU for Bluetooth LE of 251 bytes. 176 Excluding the L2CAP header of 4 bytes, a protocol data unit (PDU) 177 size of 247 bytes is available for the layer above L2CAP. (Note: 178 earlier Bluetooth LE versions offered a maximum amount of 23 bytes 179 for the layer atop L2CAP.) The L2CAP provides a fragmentation and 180 reassembly solution for transmitting or receiving larger PDUs. At 181 each link, the IPSP defines means for negotiating a link-layer 182 connection that provides an MTU of 1280 octets or higher for the IPv6 183 layer [IPSP]. The link-layer MTU is negotiated separately for each 184 direction. Implementations that require an equal link-layer MTU for 185 the two directions SHALL use the smallest of the possibly different 186 MTU values. 188 Note that this specification allows using different MTUs in different 189 links. If an implementation requires use of the same MTU on every 190 one of its links, and a new node with a smaller MTU is added to the 191 network, a renegotiation of one or more links can occur. In the 192 worst case, the renegotiations could cascade network-wide. In that 193 case, implementers need to assess the impact of such phenomenon. 195 Similarly to RFC 7668, fragmentation functionality from 6LoWPAN 196 standards is not used for IPv6 mesh over Bluetooth LE links. 197 Bluetooth LE's fragmentation support provided by L2CAP is used when 198 necessary. 200 3.2. Subnet model 202 For IPv6 mesh over Bluetooth LE links, a multilink model has been 203 chosen, as further illustrated in Figure 2. As IPv6 over Bluetooth 204 LE is intended for constrained nodes, and for Internet of Things use 205 cases and environments, the complexity of implementing a separate 206 subnet on each peripheral-central link and routing between the 207 subnets appears to be excessive. In this specification, the benefits 208 of treating the collection of point-to-point links between a central 209 and its connected peripherals as a single multilink subnet rather 210 than a multiplicity of separate subnets are considered to outweigh 211 the multilink model's drawbacks as described in [RFC4903]. 213 / 214 .--------------------------------. / 215 / 6LR 6LN 6LN \ / 216 / \ \ \ \ / 217 | \ \ \ | / 218 | 6LN ----- 6LR --------- 6LR ------ 6LBR ----- | Internet 219 | <--Link--> <---Link--->/<--Link->/ | | 220 \ / / / \ 221 \ 6LN ---- 6LR ----- 6LR / \ 222 '--------------------------------' \ 223 \ 225 <------------ Subnet -----------------><---- IPv6 connection --> 226 to the Internet 228 Figure 2: Example of an IPv6 mesh over a Bluetooth LE network 229 connected to the Internet 231 One or more 6LBRs are connected to the Internet. 6LNs are connected 232 to the network through a 6LR or a 6LBR. A prefix is used on the 233 whole subnet. 235 IPv6 mesh over Bluetooth LE links MUST follow a route-over approach. 236 This document does not specify the routing protocol to be used in an 237 IPv6 mesh over Bluetooth LE links. 239 3.3. Link model 241 3.3.1. Stateless address autoconfiguration 243 6LN, 6LR and 6LBR IPv6 addresses in an IPv6 mesh over Bluetooth LE 244 links are configured as per section 3.2.2 of RFC 7668. 246 Multihop DAD functionality as defined in section 8.2 of RFC 6775 and 247 updated by RFC 8505, or some substitute mechanism (see section 248 3.3.2), MUST be supported. 250 3.3.2. Neighbor Discovery 252 'Neighbor Discovery Optimization for IPv6 over Low-Power Wireless 253 Personal Area Networks (6LoWPANs)' [RFC6775], subsequently updated by 254 'Registration Extensions for IPv6 over Low-Power Wireless Personal 255 Area Network (6LoWPAN) Neighbor Discovery' [RFC8505], describes the 256 neighbor discovery functionality adapted for use in several 6LoWPAN 257 topologies, including the mesh topology. The route-over 258 functionality of RFC 6775 and RFC 8505 MUST be supported. 260 The following aspects of the Neighbor Discovery optimizations for 261 6LoWPAN [RFC6775],[RFC8505] are applicable to Bluetooth LE 6LNs: 263 1. A Bluetooth LE host MUST register its non-link-local addresses 264 with its routers by sending a Neighbor Solicitation (NS) message with 265 the Extended Address Registration Option (EARO) and process the 266 Neighbor Advertisement (NA) accordingly. The NS with the EARO option 267 MUST be sent irrespective of the method used to generate the IID. 268 The EARO option includes a Registration Ownership Verifier (ROVR) 269 field [RFC8505]. In the case of Bluetooth LE, by default the ROVR 270 field is filled with the 48-bit device address used by the Bluetooth 271 LE node converted into 64-bit Modified EUI-64 format [RFC4291]. 272 Optionally, a cryptographic ID (see [I-D.ietf-6lo-ap-nd] MAY be 273 placed in the ROVR field. If a cryptographic ID is used, address 274 registration and multihop DAD formats and procedures defined in 275 [I-D.ietf-6lo-ap-nd] MUST be used, unless an alternative mechanism 276 offering equivalent protection is used. As per RFC 8505, a 6LN MUST 277 NOT register its link-local address. 279 If the 6LN registers for a same compression context multiple 280 addresses that are not based on Bluetooth device address, the header 281 compression efficiency will decrease. 283 2. For sending Router Solicitations and processing Router 284 Advertisements the Bluetooth LE hosts MUST, respectively, follow 285 Sections 5.3 and 5.4 of [RFC6775], and Section 5.6 of [RFC8505]. 287 3. The router behavior for 6LRs and 6LBRs is described in Section 6 288 of RFC 6775, and updated by RFC 8505. However, as per this 289 specification: a) Routers SHALL NOT use multicast NSs to discover 290 other routers' link layer addresses. b) As per section 6.2 of RFC 291 6775, in a dynamic configuration scenario, a 6LR comes up as a non- 292 router and waits to receive a Router Advertisement for configuring 293 its own interface address first, before setting its interfaces to be 294 advertising interfaces and turning into a router. In order to 295 support such operation in an IPv6 mesh over Bluetooth LE links, a 6LR 296 first uses the IPSP Node role only. Once the 6LR has established a 297 connection with another node previously running as a router, and 298 receives a Router Advertisement from that router, the 6LR configures 299 its own interface address, it turns into a router, and it runs as an 300 IPSP Router. A 6LBR uses the IPSP Router role since the 6LBR is 301 initialized. See an example in the Appendix. 303 4. Border router behavior is described in Section 7 of RFC 6775, and 304 updated by RFC 8505. 306 RFC 6775 defines substitutable mechanisms for distributing prefixes 307 and context information (section 8.1 of RFC 6775), as well as for 308 Duplicate Address Detection across a route-over 6LoWPAN (section 8.2 309 of RFC 6775). RFC 8505 updates those mechanisms and the related 310 message formats. Implementations of this specification MUST support 311 the features described in sections 8.1 and 8.2 of RFC 6775, as 312 updated by RFC 8505, unless some alternative ("substitute") from some 313 other specification is supported by the implementation. 315 3.3.3. Header compression 317 Header compression as defined in RFC 6282 [RFC6282], which specifies 318 the compression format for IPv6 datagrams on top of IEEE 802.15.4, is 319 REQUIRED as the basis for IPv6 header compression on top of Bluetooth 320 LE. All headers MUST be compressed according to RFC 6282 [RFC6282] 321 encoding formats. 323 To enable efficient header compression, when the 6LBR sends a Router 324 Advertisement it MUST include a 6LoWPAN Context Option (6CO) 325 [RFC6775] matching each address prefix advertised via a Prefix 326 Information Option (PIO) [RFC4861] for use in stateless address 327 autoconfiguration. 329 The specific optimizations of RFC 7668 for header compression, which 330 exploit the star topology and ARO, cannot be generalized in an IPv6 331 mesh over Bluetooth LE links. Still, a subset of those optimizations 332 can be applied in some cases in such a network. In particular, the 333 latter comprise link-local interactions, non-link- local packet 334 transmissions originated and performed by a 6LN, and non-link-local 335 packets transmitted (but not necessarily originated) by the neighbor 336 of a 6LN to that 6LN. For the rest of packet transmissions, context- 337 based compression MAY be used. 339 When a device transmits a packet to a neighbor, the sender MUST fully 340 elide the source IID if the source IPv6 address is the link-local 341 address based on the sender's Bluetooth device address (SAC=0, 342 SAM=11). The sender also MUST fully elide the destination IPv6 343 address if it is the link-local address based on the neighbor's 344 Bluetooth device address (DAC=0, DAM=11). 346 A 6LN SHOULD register its non-link-local address with ARO in the 347 next-hop router. Note that in some cases (e.g. very short-lived 348 connections) it may not be worthwhile for a 6LN to send an NS with 349 ARO for registering its address. When a 6LN transmits a packet, with 350 a non-link-local source address that the 6LN has registered with ARO 351 in the next-hop router for the indicated prefix, the source address 352 MUST be fully elided if it is the latest address that the 6LN has 353 registered for the indicated prefix (SAC=1, SAM=11). If the source 354 non-link-local address is not the latest registered by the 6LN, then 355 the 64 bits of the IID SHALL be fully carried in-line (SAC=1, SAM=01) 356 or if the first 48 bits of the IID match with the latest address 357 registered by the 6LN, then the last 16 bits of the IID SHALL be 358 carried in-line (SAC=1, SAM=10). 360 When a router transmits a packet to a neighboring 6LN, with a non- 361 link-local destination address, the router MUST fully elide the 362 destination IPv6 address if the destination address is the latest 363 registered by the 6LN with ARO for the indicated context (DAC=1, 364 DAM=11). If the destination address is a non-link-local address and 365 not the latest registered, then the 6LN MUST either include the IID 366 part fully in-line (DAM=01) or, if the first 48 bits of the IID match 367 to the latest registered address, then elide those 48 bits (DAM=10). 369 3.3.4. Unicast and multicast mapping 371 The Bluetooth LE Link Layer does not support multicast. Hence, 372 traffic is always unicast between two Bluetooth LE neighboring nodes. 373 If a node needs to send a multicast packet to several neighbors, it 374 has to replicate the packet and unicast it on each link. However, 375 this may not be energy efficient, and particular care must be taken 376 if the node is battery powered. A router (i.e. a 6LR or a 6LBR) MUST 377 keep track of neighboring multicast listeners, and it MUST NOT 378 forward multicast packets to neighbors that have not registered as 379 listeners for multicast groups the packets belong to. 381 4. IANA Considerations 383 There are no IANA considerations related to this document. 385 5. Security Considerations 387 The security considerations in RFC 7668 apply. 389 IPv6 mesh over Bluetooth LE links requires a routing protocol to find 390 end-to-end paths. Unfortunately, the routing protocol may generate 391 additional opportunities for threats and attacks to the network. 393 RFC 7416 [RFC 7416] provides a systematic overview of threats and 394 attacks on the IPv6 Routing Protocol for Low-Power and Lossy Networks 395 (RPL), as well as countermeasures. In that document, described 396 threats and attacks comprise threats due to failures to authenticate, 397 threats due to failure to keep routing information, threats and 398 attacks on integrity, and threats and attacks on availability. 399 Reported countermeasures comprise confidentiality attack, integrity 400 attack, and availability attack countermeasures. 402 While this specification does not state the routing protocol to be 403 used in IPv6 mesh over Bluetooth LE links, the guidance of RFC 7416 404 is useful when RPL is used in such scenarios. Furthermore, such 405 guidance may partly apply for other routing protocols as well. 407 The ROVR can be derived from the Bluetooth device address. However, 408 such a ROVR can be spoofed, and therefore, any node connected to the 409 subnet and aware of a registered-address-to-ROVR mapping could 410 perform address theft and impersonation attacks. Use of Address 411 Protected Neighbor Discovery [I-D.ietf-6lo-ap-nd] provides protection 412 against such attacks. 414 6. Contributors 416 Carlo Alberto Boano (Graz University of Technology) contributed to 417 the design and validation of this document. 419 7. Acknowledgements 421 The Bluetooth, Bluetooth Smart and Bluetooth Smart Ready marks are 422 registered trademarks owned by Bluetooth SIG, Inc. 424 The authors of this document are grateful to all RFC 7668 authors, 425 since this document borrows many concepts (albeit, with necessary 426 extensions) from RFC 7668. 428 The authors also thank Alain Michaud, Mark Powell, Martin Turon, 429 Bilhanan Silverajan, Rahul Jadhav and Pascal Thubert for their 430 comments, which helped improve the document. 432 Carles Gomez has been supported in part by the Spanish Government 433 Ministerio de Economia y Competitividad through projects 434 TEC2012-32531, TEC2016-79988-P and FEDER. 436 8. Appendix 438 This appendix provides an example of Bluetooth LE connection 439 establishment and use of IPSP roles in an IPv6 mesh over Bluetooth LE 440 links that uses dynamic configuration. The example follows text in 441 Section 3.3.2, item 3.b). 443 The example assumes a network with one 6LBR, two 6LRs and three 6LNs, 444 as shown in Figure 3. Connectivity between the 6LNs and the 6LBR is 445 only possible via the 6LRs. 447 The following text describes the different steps as time evolves, in 448 the example. Note that other sequences of events that may lead to 449 the same final scenario are also possible. 451 At the beginning, the 6LBR starts running as an IPSP Router, whereas 452 the rest of devices are not yet initialized (Step 1). Next, the 6LRs 453 start running as IPSP Nodes, i.e., they use Bluetooth LE 454 advertisement packets to announce their presence and support of IPv6 455 capabilities (Step 2). The 6LBR (already running as an IPSP Router) 456 discovers the presence of the 6LRs and establishes one Bluetooth LE 457 connection with each 6LR (Step 3). After establishment of those link 458 layer connections (and after reception of Router Advertisements from 459 the 6LBR), Step 4, the 6LRs start operating as routers, and also 460 initiate the IPSP Router role (note: whether the IPSP Node role is 461 kept running simultaneously is an implementation decision). Then, 462 6LNs start running the IPSP Node role (Step 5). Finally, the 6LRs 463 discover presence of the 6LNs and establish connections with the 464 latter (Step 6). 466 Step 1 467 ****** 468 6LBR 469 (IPSP: Router) 471 6LR 6LR 472 (not initialized) (not initialized) 474 6LN 6LN 6LN 475 (not initialized) (not initialized) (not initialized) 477 Step 2 478 ****** 479 6LBR 480 (IPSP: Router) 482 6LR 6LR 483 (IPSP: Node) (IPSP: Node) 485 6LN 6LN 6LN 486 (not initialized) (not initialized) (not initialized) 488 Step 3 489 ****** 491 6LBR 492 (IPSP: Router) 493 Bluetooth LE connection --> / \ 494 / \ 495 6LR 6LR 496 (IPSP: Node) (IPSP: Node) 498 6LN 6LN 6LN 499 (not initialized) (not initialized) (not initialized) 501 Step 4 502 ****** 504 6LBR 505 (IPSP: Router) 506 / \ 508 / \ 509 6LR 6LR 510 (IPSP: Router) (IPSP: Router) 512 6LN 6LN 6LN 513 (not initialized) (not initialized) (not initialized) 515 Step 5 516 ****** 518 6LBR 519 (IPSP: Router) 520 / \ 521 / \ 522 6LR 6LR 523 (IPSP: Router) (IPSP: Router) 525 6LN 6LN 6LN 526 (IPSP: Node) (IPSP: Node) (IPSP: Node) 528 Step 6 529 ****** 531 6LBR 532 (IPSP: Router) 533 / \ 534 / \ 535 6LR 6LR 536 (IPSP: Router) (IPSP: Router) 537 / \ / \ 538 / \ / \ 539 / \ / \ 540 6LN 6LN 6LN 541 (IPSP: Node) (IPSP: Node) (IPSP: Node) 543 Figure 3: An example of connection establishment and use of IPSP 544 roles in an IPv6 mesh over Bluetooth LE links. 546 9. References 548 9.1. Normative References 550 [BTCorev4.2] 551 Bluetooth Special Interest Group, "Bluetooth Core 552 Specification Version 4.2", December 2014, 553 . 556 [IPSP] Bluetooth Special Interest Group, "Bluetooth Internet 557 Protocol Support Profile Specification Version 1.0.0", 558 December 2014, . 561 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 562 Requirement Levels", BCP 14, RFC 2119, 563 DOI 10.17487/RFC2119, March 1997, 564 . 566 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 567 Architecture", RFC 4291, DOI 10.17487/RFC4291, February 568 2006, . 570 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 571 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 572 DOI 10.17487/RFC4861, September 2007, 573 . 575 [RFC6282] Hui, J., Ed. and P. Thubert, "Compression Format for IPv6 576 Datagrams over IEEE 802.15.4-Based Networks", RFC 6282, 577 DOI 10.17487/RFC6282, September 2011, 578 . 580 [RFC6775] Shelby, Z., Ed., Chakrabarti, S., Nordmark, E., and C. 581 Bormann, "Neighbor Discovery Optimization for IPv6 over 582 Low-Power Wireless Personal Area Networks (6LoWPANs)", 583 RFC 6775, DOI 10.17487/RFC6775, November 2012, 584 . 586 [RFC7668] Nieminen, J., Savolainen, T., Isomaki, M., Patil, B., 587 Shelby, Z., and C. Gomez, "IPv6 over BLUETOOTH(R) Low 588 Energy", RFC 7668, DOI 10.17487/RFC7668, October 2015, 589 . 591 [RFC8505] Thubert, P., Ed., Nordmark, E., Chakrabarti, S., and C. 592 Perkins, "Registration Extensions for IPv6 over Low-Power 593 Wireless Personal Area Network (6LoWPAN) Neighbor 594 Discovery", RFC 8505, DOI 10.17487/RFC8505, November 2018, 595 . 597 9.2. Informative References 599 [BTCorev4.1] 600 Bluetooth Special Interest Group, "Bluetooth Core 601 Specification Version 4.1", December 2013, 602 . 605 [I-D.ietf-6lo-ap-nd] 606 Thubert, P., Sarikaya, B., Sethi, M., and R. Struik, 607 "Address Protected Neighbor Discovery for Low-power and 608 Lossy Networks", draft-ietf-6lo-ap-nd-11 (work in 609 progress), February 2019. 611 [RFC4903] Thaler, D., "Multi-Link Subnet Issues", RFC 4903, 612 DOI 10.17487/RFC4903, June 2007, 613 . 615 [RFC7416] Tsao, T., Alexander, R., Dohler, M., Daza, V., Lozano, A., 616 and M. Richardson, Ed., "A Security Threat Analysis for 617 the Routing Protocol for Low-Power and Lossy Networks 618 (RPLs)", RFC 7416, DOI 10.17487/RFC7416, January 2015, 619 . 621 Authors' Addresses 623 Carles Gomez 624 Universitat Politecnica de Catalunya 625 C/Esteve Terradas, 7 626 Castelldefels 08860 627 Spain 629 Email: carlesgo@entel.upc.edu 631 Seyed Mahdi Darroudi 632 Universitat Politecnica de Catalunya 633 C/Esteve Terradas, 7 634 Castelldefels 08860 635 Spain 637 Email: sm.darroudi@entel.upc.edu 638 Teemu Savolainen 639 DarkMatter LLC 641 Email: teemu.savolainen@darkmatter.ae 643 Michael Spoerk 644 Graz University of Technology 645 Inffeldgasse 16/I 646 Graz 8010 647 Austria 649 Email: michael.spoerk@tugraz.at