idnits 2.17.1 draft-ietf-6lo-blemesh-00.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 (November 13, 2016) is 2720 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 337, but not defined == Unused Reference: 'RFC7668' is defined on line 406, but no explicit reference was found in the text == Unused Reference: 'RFC7416' is defined on line 417, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'IPSP' Summary: 0 errors (**), 0 flaws (~~), 4 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 UPC/i2cat 5 Expires: May 17, 2017 T. Savolainen 6 Nokia 7 November 13, 2016 9 IPv6 Mesh over BLUETOOTH(R) Low Energy using IPSP 10 draft-ietf-6lo-blemesh-00 12 Abstract 14 RFC 7668 describes the adaptation of 6LoWPAN techniques to enable 15 IPv6 over Bluetooth low energy networks that follow the star 16 topology. However, recent Bluetooth specifications allow the 17 formation of extended topologies as well. This document specifies 18 the mechanisms needed to enable IPv6 over mesh networks composed of 19 Bluetooth low energy links established by using the Bluetooth 20 Internet Protocol Support Profile. 22 Status of This Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at http://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on May 17, 2017. 39 Copyright Notice 41 Copyright (c) 2016 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (http://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 57 1.1. Terminology and Requirements Language . . . . . . . . . . 3 58 2. Bluetooth LE Networks and the IPSP . . . . . . . . . . . . . 3 59 3. Specification of IPv6 mesh over Bluetooth LE networks . . . . 3 60 3.1. Protocol stack . . . . . . . . . . . . . . . . . . . . . 4 61 3.2. Subnet model . . . . . . . . . . . . . . . . . . . . . . 4 62 3.3. Link model . . . . . . . . . . . . . . . . . . . . . . . 5 63 3.3.1. Stateless address autoconfiguration . . . . . . . . . 5 64 3.3.2. Neighbor Discovery . . . . . . . . . . . . . . . . . 5 65 3.3.3. Header compression . . . . . . . . . . . . . . . . . 6 66 3.3.4. Unicast and multicast mapping . . . . . . . . . . . . 7 67 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 68 5. Security Considerations . . . . . . . . . . . . . . . . . . . 8 69 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 70 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 71 7.1. Normative References . . . . . . . . . . . . . . . . . . 9 72 7.2. Informative References . . . . . . . . . . . . . . . . . 9 73 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 75 1. Introduction 77 Bluetooth low energy (hereinafter, Bluetooth LE) was first introduced 78 in the Bluetooth 4.0 specification. Bluetooth LE (which has been 79 marketed as Bluetooth Smart) is a low-power wireless technology 80 designed for short-range control and monitoring applications. 81 Bluetooth LE is currently implemented in a wide range of consumer 82 electronics devices, such as smartphones and wearable devices. Given 83 the high potential of this technology for the Internet of Things, the 84 Bluetooth Special Interest Group (Bluetooth SIG) and the IETF have 85 produced specifications in order to enable IPv6 over Bluetooth LE, 86 such as the Internet Protocol Support Profile (IPSP) [IPSP], and RFC 87 7668, respectively. Bluetooth 4.0 only supports Bluetooth LE 88 networks that follow the star topology. In consequence, RFC 7668 was 89 specifically developed and optimized for that type of network 90 topology. However, subsequent Bluetooth specifications allow the 91 formation of extended topologies [BTCorev4.1], such as the mesh 92 topology. The functionality described in RFC 7668 is not sufficient 93 and would fail to enable IPv6 over mesh networks composed of 94 Bluetooth LE links. This document specifies the mechanisms needed to 95 enable IPv6 over mesh networks composed of Bluetooth LE links. This 96 specification also allows to run IPv6 over Bluetooth LE star topology 97 networks, albeit without all the topology-specific optimizations 98 contained in RFC 7668. 100 1.1. Terminology and Requirements Language 102 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 103 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 104 document are to be interpreted as described in RFC 2119 [RFC2119]. 106 The terms 6LoWPAN Node (6LN), 6LoWPAN Router (6LR) and 6LoWPAN Border 107 Router (6LBR) are defined as in [RFC6775], with an addition that 108 Bluetooth LE central and Bluetooth LE peripheral (see Section 2) can 109 both be adopted by a 6LN, a 6LR or a 6LBR. 111 2. Bluetooth LE Networks and the IPSP 113 Bluetooth LE defines two Generic Access Profile (GAP) roles of 114 relevance herein: the Bluetooth LE central role and the Bluetooth LE 115 peripheral role. A device in the central role, which is called 116 central from now on, has traditionally been able to manage multiple 117 simultaneous connections with a number of devices in the peripheral 118 role, called peripherals hereinafter. Bluetooth 4.1 introduced the 119 possibility for a peripheral to be connected to more than one central 120 simultaneously, therefore allowing extended topologies beyond the 121 star topology for a Bluetooth LE network. In addition, a device may 122 simultaneously be a central in a set of link layer connections, as 123 well as a peripheral in others. On the other hand, the IPSP enables 124 discovery of IP-enabled devices and the establishment of a link layer 125 connection for transporting IPv6 packets. The IPSP defines the Node 126 and Router roles for devices that consume/originate IPv6 packets and 127 for devices that can route IPv6 packets, respectively. Consistently 128 with Bluetooth 4.1, a device may implement both roles simultaneously. 130 This document assumes a mesh network composed of Bluetooth LE links, 131 where link layer connections have been established between 132 neighboring IPv6-enabled devices. The IPv6 forwarding devices of the 133 mesh have to implement both Node and Router roles, while simpler 134 leaf-only nodes can implement only the Node role. In an IPv6-enabled 135 mesh of Bluetooth LE links, a node is a neighbor of another node, and 136 vice versa, if a link layer connection has been established between 137 both by using the IPSP functionality for discovery and link layer 138 connection establishment for IPv6 packet transport. 140 3. Specification of IPv6 mesh over Bluetooth LE networks 141 3.1. Protocol stack 143 Figure 1 illustrates the protocol stack for IPv6 mesh over Bluetooth 144 LE networks. There are two main differences with the IPv6 over 145 Bluetooth LE stack in RFC 7668: a) the adaptation layer below IPv6 146 (labelled as "6Lo for mesh of Bluetooth LE") is now adapted for mesh 147 networks of Bluetooth LE links, and b) the protocol stack for IPv6 148 mesh networks of Bluetooth LE links includes IPv6 routing 149 functionality. 151 +------------------------------------+ 152 | Application | 153 +---------+ +------------------------------------+ 154 | IPSS | | UDP/TCP/other | 155 +---------+ +------------------------------------+ 156 | GATT | | IPv6 |routing| | 157 +---------+ +------------------------------------+ 158 | ATT | | 6Lo for IPv6 mesh over Bluetooh LE | 159 +---------+--+------------------------------------+ 160 | Bluetooth LE L2CAP | 161 - - +-------------------------------------------------+- - - HCI 162 | Bluetooth LE Link Layer | 163 +-------------------------------------------------+ 164 | Bluetooth LE Physical | 165 +-------------------------------------------------+ 167 Figure 1: Protocol stack for IPv6 mesh over Bluetooth LE. 169 3.2. Subnet model 171 For IPv6 mesh over Bluetooth LE, a multilink model has been chosen, 172 as further illustrated in Figure 2. As IPv6 over Bluetooth LE is 173 intended for constrained nodes, and for Internet of Things use cases 174 and environments, the complexity of implementing a separate subnet on 175 each peripheral-central link and routing between the subnets appears 176 to be excessive. In this specification, the benefits of treating the 177 collection of point-to-point links between a central and its 178 connected peripherals as a single multilink subnet rather than a 179 multiplicity of separate subnets are considered to outweigh the 180 multilink model's drawbacks as described in [RFC4903]. 182 / 183 .--------------------------------. / 184 / 6LR 6LN 6LN \ / 185 / \ \ \ \ / 186 | \ \ \ | / 187 | 6LN ----- 6LR --------- 6LR ------ 6LBR ----- | Internet 188 | <--Link--> <---Link--->/<--Link->/ | | 189 \ / / / \ 190 \ 6LN ---- 6LR ----- 6LR / \ 191 '--------------------------------' \ 192 \ 194 <------------ Subnet -----------------><---- IPv6 connection --> 195 to the Internet 197 Figure 2: Example of an IPv6 mesh over a Bluetooth LE network 198 connected to the Internet 200 One or more 6LBRs are connected to the Internet. 6LNs are connected 201 to the network through a 6LR or a 6LBR. A prefix is used on the 202 whole subnet. 204 IPv6 mesh networks over Bluetooth LE MUST follow a route-over 205 approach. This document does not specify the routing protocol to be 206 used in an IPv6 mesh over Bluetooth LE. 208 3.3. Link model 210 3.3.1. Stateless address autoconfiguration 212 6LN, 6LR and 6LBR IPv6 addresses in an IPv6 mesh over Bluetooth LE 213 are configured as per section 3.2.2 of RFC 7668. 215 Multihop DAD functionality as defined in section 8.2 of RFC 6775, or 216 some substitute mechanism (see section 3.3.2), MUST be supported. 218 3.3.2. Neighbor Discovery 220 'Neighbor Discovery Optimization for IPv6 over Low-Power Wireless 221 Personal Area Networks (6LoWPANs)' [RFC6775] describes the neighbor 222 discovery approach as adapted for use in several 6LoWPAN topologies, 223 including the mesh topology. The route-over functionality of RFC 224 6775 MUST be supported. 226 The following aspects of the Neighbor Discovery optimizations 227 [RFC6775] are applicable to Bluetooth LE 6LNs: 229 1. A Bluetooth LE 6LN MUST NOT register its link-local address. A 230 Bluetooth LE 6LN MUST register its non-link-local addresses with its 231 routers by sending a Neighbor Solicitation (NS) message with the 232 Address Registration Option (ARO) and process the Neighbor 233 Advertisement (NA) accordingly. The NS with the ARO option MUST be 234 sent irrespective of the method used to generate the IID. The ARO 235 option requires use of an EUI-64 identifier [RFC6775]. In the case 236 of Bluetooth LE, the field SHALL be filled with the 48-bit device 237 address used by the Bluetooth LE node converted into 64-bit Modified 238 EUI-64 format [RFC4291]. 240 If the 6LN registers for a same compression context multiple 241 addresses that are not based on Bluetooth device address, the header 242 compression efficiency will decrease. 244 2. For sending Router Solicitations and processing Router 245 Advertisements the Bluetooth LE 6LNs MUST, respectively, follow 246 Sections 5.3 and 5.4 of the [RFC6775]. 248 3. The router behavior for 6LRs and 6LBRs is described in Section 6 249 of RFC 6775. However, as per this specification, routers SHALL NOT 250 use multicast NSs to discover other routers' link layer addresses. 252 4. Border router behavior is described in Section 7 of RFC 6775. 254 RFC 6775 defines substitutable mechanisms for distributing prefixes 255 and context information (section 8.1 of RFC 6775), as well as for 256 Duplicate Address Detection across a route-over 6LoWPAN (section 8.2 257 of RFC 6775). Implementations of this specification MUST support the 258 features described in sections 8.1 and 8.2 of RFC 6775 unless some 259 alternative ("substitute") from some other specification is 260 supported. 262 3.3.3. Header compression 264 Header compression as defined in RFC 6282 [RFC6282], which specifies 265 the compression format for IPv6 datagrams on top of IEEE 802.15.4, is 266 REQUIRED as the basis for IPv6 header compression on top of Bluetooth 267 LE. All headers MUST be compressed according to RFC 6282 [RFC6282] 268 encoding formats. 270 To enable efficient header compression, when the 6LBR sends a Router 271 Advertisement it MUST include a 6LoWPAN Context Option (6CO) 272 [RFC6775] matching each address prefix advertised via a Prefix 273 Information Option (PIO) [RFC4861] for use in stateless address 274 autoconfiguration. 276 The specific optimizations of RFC 7668 for header compression, which 277 exploit the star topology and ARO, cannot be generalized in a mesh 278 network composed of Bluetooth LE links. Still, a subset of those 279 optimizations can be applied in some cases in such a network. In 280 particular, the latter comprise link-local interactions, non-link- 281 local packet transmissions originated and performed by a 6LN, and 282 non-link-local packet transmissions originated by a 6LN neighbor and 283 sent to a 6LN. For the rest of packet transmissions, context-based 284 compression MAY be used. 286 When a device transmits a packet to a neighbor, the sender MUST fully 287 elide the source IID if the source IPv6 address is the link-local 288 address based on the sender's Bluetooth device address (SAC=0, 289 SAM=11). The sender also MUST fully elide the destination IPv6 290 address if it is the link-local-address based on the neighbor's 291 Bluetooth device address (DAC=0, DAM=11). 293 When a 6LN transmits a packet, with a non-link-local source address 294 that the 6LN has registered with ARO in the next-hop router for the 295 indicated prefix, the source address MUST be fully elided if it is 296 the latest address that the 6LN has registered for the indicated 297 prefix (SAC=1, SAM=11). If the source non-link-local address is not 298 the latest registered by the 6LN, then the 64-bits of the IID SHALL 299 be fully carried in-line (SAC=1, SAM=01) or if the first 48-bits of 300 the IID match with the latest address registered by the 6LN, then the 301 last 16-bits of the IID SHALL be carried in-line (SAC=1, SAM=10). 303 When a router transmits a packet to a neighboring 6LN, with a non- 304 link-local destination address, the router MUST fully elide the 305 destination IPv6 address if the destination address is the latest 306 registered by the 6LN with ARO for the indicated context (DAC=1, 307 DAM=11). If the destination address is a non-link-local address and 308 not the latest registered, then the 6LN MUST either include the IID 309 part fully in-line (DAM=01) or, if the first 48-bits of the IID match 310 to the latest registered address, then elide those 48-bits (DAM=10). 312 3.3.4. Unicast and multicast mapping 314 The Bluetooth LE Link Layer does not support multicast. Hence, 315 traffic is always unicast between two Bluetooth LE neighboring nodes. 316 If a node needs to send a multicast packet to several neighbors, it 317 has to replicate the packet and unicast it on each link. However, 318 this may not be energy efficient, and particular care must be taken 319 if the node is battery powered. A router (i.e. a 6LR or a 6LBR) MUST 320 keep track of neighboring multicast listeners, and it MUST NOT 321 forward multicast packets to neighbors that have not registered as 322 listeners for multicast groups the packets belong to. 324 4. IANA Considerations 326 There are no IANA considerations related to this document. 328 5. Security Considerations 330 The security considerations in RFC 7668 apply. 332 IPv6 mesh networks over Bluetooth LE require a routing protocol to 333 find end-to-end paths. Unfortunately, the routing protocol may 334 generate additional opportunities for threats and attacks to the 335 network. 337 RFC 7416 [RFC 7416] provides a systematic overview of threats and 338 attacks on the IPv6 Routing Protocol for Low-Power and Lossy Networks 339 (RPL), as well as countermeasures. In that document, described 340 threats and attacks comprise threats due to failures to authenticate, 341 threats due to failure to keep routing information, threats and 342 attacks on integrity, and threats and attacks on availability. 343 Reported countermeasures comprise confidentiality attack, integrity 344 attack, and availability attack countermeasures. 346 While this specification does not state the routing protocol to be 347 used in IPv6 mesh over Bluetooth LE networks, the guidance of RFC 348 7416 is useful when RPL is used in such scenarios. Furthermore, such 349 guidance may partly apply for other routing protocols as well. 351 6. Acknowledgements 353 The Bluetooth, Bluetooth Smart and Bluetooth Smart Ready marks are 354 registered trademarks owned by Bluetooth SIG, Inc. 356 The authors of this document are grateful to all RFC 7668 authors, 357 since this document borrows many concepts (albeit, with necessary 358 extensions) from RFC 7668. 360 The authors also thank Alain Michaud, Mark Powell and Martin Turon 361 for their comments, which helped improve the document. 363 Carles Gomez has been supported in part by the Spanish Government 364 Ministerio de Economia y Competitividad through project 365 TEC2012-32531, and FEDER. 367 7. References 368 7.1. Normative References 370 [BTCorev4.1] 371 Bluetooth Special Interest Group, "Bluetooth Core 372 Specification Version 4.1", December 2013, 373 . 376 [IPSP] Bluetooth Special Interest Group, "Bluetooth Internet 377 Protocol Support Profile Specification Version 1.0.0", 378 December 2014, . 381 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 382 Requirement Levels", BCP 14, RFC 2119, 383 DOI 10.17487/RFC2119, March 1997, 384 . 386 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 387 Architecture", RFC 4291, DOI 10.17487/RFC4291, February 388 2006, . 390 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 391 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 392 DOI 10.17487/RFC4861, September 2007, 393 . 395 [RFC6282] Hui, J., Ed. and P. Thubert, "Compression Format for IPv6 396 Datagrams over IEEE 802.15.4-Based Networks", RFC 6282, 397 DOI 10.17487/RFC6282, September 2011, 398 . 400 [RFC6775] Shelby, Z., Ed., Chakrabarti, S., Nordmark, E., and C. 401 Bormann, "Neighbor Discovery Optimization for IPv6 over 402 Low-Power Wireless Personal Area Networks (6LoWPANs)", 403 RFC 6775, DOI 10.17487/RFC6775, November 2012, 404 . 406 [RFC7668] Nieminen, J., Savolainen, T., Isomaki, M., Patil, B., 407 Shelby, Z., and C. Gomez, "IPv6 over BLUETOOTH(R) Low 408 Energy", RFC 7668, DOI 10.17487/RFC7668, October 2015, 409 . 411 7.2. Informative References 413 [RFC4903] Thaler, D., "Multi-Link Subnet Issues", RFC 4903, 414 DOI 10.17487/RFC4903, June 2007, 415 . 417 [RFC7416] Tsao, T., Alexander, R., Dohler, M., Daza, V., Lozano, A., 418 and M. Richardson, Ed., "A Security Threat Analysis for 419 the Routing Protocol for Low-Power and Lossy Networks 420 (RPLs)", RFC 7416, DOI 10.17487/RFC7416, January 2015, 421 . 423 Authors' Addresses 425 Carles Gomez 426 Universitat Politecnica de Catalunya/Fundacio i2cat 427 C/Esteve Terradas, 7 428 Castelldefels 08860 429 Spain 431 Email: carlesgo@entel.upc.edu 433 Seyed Mahdi Darroudi 434 Universitat Politecnica de Catalunya/Fundacio i2cat 435 C/Esteve Terradas, 7 436 Castelldefels 08860 437 Spain 439 Email: sm.darroudi@entel.upc.edu 441 Teemu Savolainen 442 Nokia Technologies 443 Hatanpaan valtatie 30 444 Tampere 33100 445 Finland 447 Email: teemu.savolainen@nokia.com