idnits 2.17.1 draft-gomez-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 (October 19, 2015) is 3112 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) == Unused Reference: 'I-D.ietf-6lo-btle' is defined on line 341, but no explicit reference was found in the text == Unused Reference: 'IPSP' is defined on line 347, but no explicit reference was found in the text == Unused Reference: 'RFC4862' is defined on line 366, but no explicit reference was found in the text == Unused Reference: 'RFC7136' is defined on line 382, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-6man-default-iids' is defined on line 394, but no explicit reference was found in the text == Unused Reference: 'IEEE802-2001' is defined on line 400, but no explicit reference was found in the text == Unused Reference: 'RFC3315' is defined on line 405, but no explicit reference was found in the text == Unused Reference: 'RFC3610' is defined on line 410, but no explicit reference was found in the text == Unused Reference: 'RFC3633' is defined on line 414, but no explicit reference was found in the text == Unused Reference: 'RFC3972' is defined on line 419, but no explicit reference was found in the text == Unused Reference: 'RFC4193' is defined on line 423, but no explicit reference was found in the text == Unused Reference: 'RFC4941' is defined on line 431, but no explicit reference was found in the text == Unused Reference: 'RFC4944' is defined on line 436, but no explicit reference was found in the text == Unused Reference: 'RFC5535' is defined on line 441, but no explicit reference was found in the text == Unused Reference: 'RFC7217' is defined on line 445, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'IPSP' == Outdated reference: A later version (-16) exists of draft-ietf-6man-default-iids-08 -- Obsolete informational reference (is this intentional?): RFC 3315 (Obsoleted by RFC 8415) -- Obsolete informational reference (is this intentional?): RFC 3633 (Obsoleted by RFC 8415) -- Obsolete informational reference (is this intentional?): RFC 4941 (Obsoleted by RFC 8981) Summary: 0 errors (**), 0 flaws (~~), 17 warnings (==), 5 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: April 21, 2016 T. Savolainen 6 Nokia 7 October 19, 2015 9 IPv6 over BLUETOOTH(R) Low Energy Mesh Networks 10 draft-gomez-6lo-blemesh-00 12 Abstract 14 draft-ietf-6lo-btle describes the adaptation of 6LoWPAN techniques to 15 enable 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 defines how 18 IPv6 is transported over Bluetooth low energy mesh networks. 20 Status of This Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at http://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on April 21, 2016. 37 Copyright Notice 39 Copyright (c) 2015 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (http://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 55 1.1. Terminology and Requirements Language . . . . . . . . . . 3 56 2. Bluetooth LE Mesh Networks . . . . . . . . . . . . . . . . . 3 57 3. Specification of IPv6 over Bluetooth LE mesh networks . . . . 3 58 3.1. Protocol stack . . . . . . . . . . . . . . . . . . . . . 3 59 3.2. Subnet model . . . . . . . . . . . . . . . . . . . . . . 4 60 3.3. Link model . . . . . . . . . . . . . . . . . . . . . . . 5 61 3.3.1. Stateless address autoconfiguration . . . . . . . . . 5 62 3.3.2. Neighbor Discovery . . . . . . . . . . . . . . . . . 5 63 3.3.3. Header compression . . . . . . . . . . . . . . . . . 6 64 3.3.4. Unicast and multicast mapping . . . . . . . . . . . . 7 65 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 66 5. Security Considerations . . . . . . . . . . . . . . . . . . . 7 67 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 68 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 69 7.1. Normative References . . . . . . . . . . . . . . . . . . 8 70 7.2. Informative References . . . . . . . . . . . . . . . . . 9 71 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 73 1. Introduction 75 Bluetooth low energy (hereinafter, Bluetooth LE) was first introduced 76 in the Bluetooth 4.0 specification. Bluetooth LE (which has been 77 marketed as Bluetooth Smart) is a low-power wireless technology 78 designed for short-range control and monitoring applications. 79 Bluetooth LE is currently implemented in a wide range of consumer 80 electronics devices, such as smartphones and wearable devices. Given 81 the high potential of this technology for the Internet of Things, the 82 Bluetooth Special Interest Group (Bluetooth SIG) and the IETF have 83 produced specifications in order to enable IPv6 over Bluetooth LE, 84 such as the Internet Protocol Support Profile (IPSP), and draft-ietf- 85 6lo-btle, respectively. Bluetooth 4.0 only supports Bluetooth LE 86 networks that follow the star topology. In consequence, draft-ietf- 87 6lo-btle was specifically developed and optimized for that type of 88 network topology. However, subsequent Bluetooth specifications allow 89 the formation of extended topologies, such as the mesh topology. The 90 functionality described in draft-ietf-6lo-btle is not sufficient and 91 would fail to enable IPv6 over Bluetooth LE mesh networks. This 92 document specifies the mechanisms needed to enable IPv6 over 93 Bluetooth LE mesh networks. This specification also allows to run 94 IPv6 over Bluetooth LE star topology networks, albeit without all the 95 topology-specific optimizations contained in draft-ietf-6lo-btle. 97 1.1. Terminology and Requirements Language 99 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 100 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 101 document are to be interpreted as described in RFC 2119 [RFC2119]. 103 The terms 6LoWPAN Node (6LN), 6LoWPAN Router (6LR) and 6LoWPAN Border 104 Router (6LBR) are defined as in [RFC6775], with an addition that 105 Bluetooth LE central and Bluetooth LE peripheral (see Section 2) can 106 both be adopted by a 6LN, a 6LR or a 6LBR. 108 2. Bluetooth LE Mesh Networks 110 Bluetooth LE defines two Generic Access Profile (GAP) roles of 111 relevance herein: the Bluetooth LE central role and the Bluetooth LE 112 peripheral role. A device in the central role, which is called 113 central from now on, has traditionally been able to manage multiple 114 simultaneous connections with a number of devices in the peripheral 115 role, called peripherals hereinafter. Bluetooth 4.1 introduced the 116 possibility for a peripheral to be connected to more than one central 117 simultaneously, therefore allowing extended topologies beyond the 118 star topology for a Bluetooth LE network. In addition, a device may 119 simultaneously be a central in a set of link layer connections, as 120 well as a peripheral in others. On the other hand, the IPSP enables 121 discovery of IP-enabled devices and the establishment of a link layer 122 connection for transporting IPv6 packets. The IPSP defines the Node 123 and Router roles for devices that consume/originate IPv6 packets and 124 for devices that can route IPv6 packets, respectively. Consistently 125 with Bluetooth 4.1, a device may implement both roles simultaneously. 127 This document assumes a Bluetooth LE mesh network whereby link layer 128 connections have been established between neighboring IPv6-enabled 129 devices. In an IPv6-enabled Bluetooth LE mesh network, a node is a 130 neighbor of another node, and vice versa, if a link layer connection 131 has been established between both by using the IPSP functionality for 132 discovery and link layer connection establishment for IPv6 packet 133 transport. 135 3. Specification of IPv6 over Bluetooth LE mesh networks 137 3.1. Protocol stack 139 Figure 1 illustrates the protocol stack for IPv6-enabled Bluetooth LE 140 mesh networks. There are two main differences with the IPv6 over 141 Bluetooth LE stack in draft-ietf-6lo-btle: a) the adaptation layer 142 below IPv6 (labelled as "6Lo for Bluetooth LE mesh") is now adapted 143 for Bluetooth LE mesh networks, and b) the protocol stack for IPv6 144 over Bluetooth LE mesh networks includes IPv6 routing functionality. 146 +----------------------------+ 147 | Application | 148 +---------+ +----------------------------+ 149 | IPSS | | UDP/TCP/other | 150 +---------+ +----------------------------+ 151 | GATT | | IPv6 |routing| | 152 +---------+ +----------------------------+ 153 | ATT | | 6Lo for Bluetooth LE Mesh | 154 +---------+--+----------------------------+ 155 | Bluetooth LE L2CAP | 156 - - +-----------------------------------------+- - - HCI 157 | Bluetooth LE Link Layer | 158 +-----------------------------------------+ 159 | Bluetooth LE Physical | 160 +-----------------------------------------+ 162 Figure 1: Protocol stack for IPv6-enabled Bluetooth LE mesh networks 164 3.2. Subnet model 166 For IPv6-based Bluetooth LE mesh networks, a multilink model has been 167 chosen, as further illustrated in Figure 2. As IPv6 over Bluetooth 168 LE is intended for constrained nodes, and for Internet of Things use 169 cases and environments, the complexity of implementing a separate 170 subnet on each peripheral-central link and routing between the 171 subnets appears to be excessive. In this specification, the benefits 172 of treating the collection of point-to-point links between a central 173 and its connected peripherals as a single multilink subnet rather 174 than a multiplicity of separate subnets are considered to outweigh 175 the multilink model's drawbacks as described in [RFC4903]. 177 / 178 .--------------------------------. / 179 / 6LR 6LN 6LN \ / 180 / \ \ \ \ / 181 | \ \ \ | / 182 | 6LN ----- 6LR --------- 6LR ------ 6LBR ----- | Internet 183 | <--Link--> <---Link--->/<--Link->/ | | 184 \ / / / \ 185 \ 6LN ---- 6LR ----- 6LR / \ 186 '--------------------------------' \ 187 \ 189 <------------ Subnet -----------------><---- IPv6 connection --> 190 to the Internet 192 Figure 2: Example of an IPv6-based Bluetooth LE mesh network 193 connected to the Internet 195 One or more 6LBRs are connected to the Internet. 6LNs are connected 196 to the network through a 6LR or a 6LBR. A prefix is used on the 197 whole subnet. 199 IPv6-enabled Bluetooth LE mesh networks MUST follow a route-over 200 approach. This document does not specify the routing protocol to be 201 used in an IPv6-enabled Bluetooth LE mesh network. 203 3.3. Link model 205 3.3.1. Stateless address autoconfiguration 207 6LN, 6LR and 6LBR IPv6 addresses of a Bluetooth LE mesh network are 208 configured as per section 3.2.2 of draft-ietf-6lo-btle. 210 Multihop DAD functionality as defined in section 8.2 of RFC 6775, or 211 some substitute mechanism (see section 3.3.2), MUST be supported. 213 3.3.2. Neighbor Discovery 215 'Neighbor Discovery Optimization for IPv6 over Low-Power Wireless 216 Personal Area Networks (6LoWPANs)' [RFC6775] describes the neighbor 217 discovery approach as adapted for use in several 6LoWPAN topologies, 218 including the mesh topology. The route-over functionality of RFC 219 6775 MUST be supported. 221 The following aspects of the Neighbor Discovery optimizations 222 [RFC6775] are applicable to Bluetooth LE 6LNs: 224 1. A Bluetooth LE 6LN MUST NOT register its link-local address. A 225 Bluetooth LE 6LN MUST register its non-link-local addresses with its 226 routers by sending a Neighbor Solicitation (NS) message with the 227 Address Registration Option (ARO) and process the Neighbor 228 Advertisement (NA) accordingly. The NS with the ARO option MUST be 229 sent irrespective of the method used to generate the IID. The ARO 230 option requires use of an EUI-64 identifier [RFC6775]. In the case 231 of Bluetooth LE, the field SHALL be filled with the 48-bit device 232 address used by the Bluetooth LE node converted into 64-bit Modified 233 EUI-64 format [RFC4291]. 235 If the 6LN registers for a same compression context multiple 236 addresses that are not based on Bluetooth device address, the header 237 compression efficiency will decrease (see the next subsection). 239 2. For sending Router Solicitations and processing Router 240 Advertisements the Bluetooth LE 6LNs MUST, respectively, follow 241 Sections 5.3 and 5.4 of the [RFC6775]. 243 6LR TBD 245 RFC 6775 defines substitutable mechanisms for distributing prefixes 246 and context information (section 8.1 of RFC 6775), as well as for 247 Duplicate Address Detection across a route-over 6LoWPAN (section 8.2 248 of RFC 6775). Implementations of this specification MUST support the 249 features described in sections 8.1 and 8.2 of RFC 6775 unless some 250 alternative ("substitute") from some other specification is 251 supported. 253 3.3.3. Header compression 255 Header compression as defined in RFC 6282 [RFC6282], which specifies 256 the compression format for IPv6 datagrams on top of IEEE 802.15.4, is 257 REQUIRED as the basis for IPv6 header compression on top of Bluetooth 258 LE. All headers MUST be compressed according to RFC 6282 [RFC6282] 259 encoding formats. 261 To enable efficient header compression, when the 6LBR sends a Router 262 Advertisement it MUST include a 6LoWPAN Context Option (6CO) 263 [RFC6775] matching each address prefix advertised via a Prefix 264 Information Option (PIO) [RFC4861] for use in stateless address 265 autoconfiguration. 267 The specific optimizations of draft-ietf-6lo-btle for header 268 compression, which exploit the star topology and ARO, cannot be 269 generalized in a Bluetooth LE mesh network. Still, a subset of those 270 optimizations can be applied in some cases in a Bluetooth LE mesh 271 network. In particular, the latter comprise link-local interactions, 272 non-link-local packet transmissions originated and performed by a 273 6LN, and non-link-local packet transmissions originated by a 6LN 274 neighbor and sent to a 6LN. For the rest of packet transmissions, 275 context-based compression MAY be used. 277 When a device transmits a packet to a neighbor, the sender MUST fully 278 elide the source IID if the source IPv6 address is the link-local 279 address based on the sender's Bluetooth device address (SAC=0, 280 SAM=11). The sender also MUST fully elide the destination IPv6 281 address if it is the link-local-address based on the neighbor's 282 Bluetooth device address (DAC=0, DAM=11). 284 When a 6LN transmits a packet, with a non-link-local source address 285 that the 6LN has registered with ARO in the next-hop router for the 286 indicated prefix, the source address MUST be fully elided if it is 287 the latest address that the 6LN has registered for the indicated 288 prefix (SAC=1, SAM=11). If the source non-link-local address is not 289 the latest registered by the 6LN, then the 64-bits of the IID SHALL 290 be fully carried in-line (SAC=1, SAM=01) or if the first 48-bits of 291 the IID match with the latest address registered by the 6LN, then the 292 last 16-bits of the IID SHALL be carried in-line (SAC=1, SAM=10). 294 When a router transmits a packet to a neighboring 6LN, with a non- 295 link-local destination address, the router MUST fully elide the 296 destination IPv6 address if the destination address is the latest 297 registered by the 6LN with ARO for the indicated context (DAC=1, 298 DAM=11). If the destination address is a non-link-local address and 299 not the latest registered, then the 6LN MUST either include the IID 300 part fully in-line (DAM=01) or, if the first 48-bits of the IID match 301 to the latest registered address, then elide those 48-bits (DAM=10). 303 3.3.4. Unicast and multicast mapping 305 TBD 307 4. IANA Considerations 309 There are no IANA considerations related to this document. 311 5. Security Considerations 313 The security considerations in draft-ietf-6lo-btle apply. 315 Further security considerations on additional threats due to ad-hoc 316 routing. TBD. 318 6. Acknowledgements 320 The Bluetooth, Bluetooth Smart and Bluetooth Smart Ready marks are 321 registred trademarks owned by Bluetooth SIG, Inc. 323 The authors of this document are grateful to all draft-ietf-6lo-btle 324 authors, since this document borrows many concepts (albeit, with 325 necessary extensions) from draft-ietf-6lo-btle. 327 Carles Gomez has been supported in part by the Spanish Government 328 Ministerio de Economia y Competitividad through project 329 TEC2012-32531, and FEDER. 331 7. References 333 7.1. Normative References 335 [BTCorev4.1] 336 Bluetooth Special Interest Group, "Bluetooth Core 337 Specification Version 4.1", December 2013, 338 . 341 [I-D.ietf-6lo-btle] 342 Nieminen, J., Savolainen, T., Isomaki, M., Patil, B., 343 Shelby, Z., and C. Gomez, "IPv6 over BLUETOOTH(R) Low 344 Energy", draft-ietf-6lo-btle-17 (work in progress), August 345 2015. 347 [IPSP] Bluetooth Special Interest Group, "Bluetooth Internet 348 Protocol Support Profile Specification Version 1.0.0", 349 December 2014, . 352 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 353 Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/ 354 RFC2119, March 1997, 355 . 357 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 358 Architecture", RFC 4291, DOI 10.17487/RFC4291, February 359 2006, . 361 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 362 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 363 DOI 10.17487/RFC4861, September 2007, 364 . 366 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 367 Address Autoconfiguration", RFC 4862, DOI 10.17487/ 368 RFC4862, September 2007, 369 . 371 [RFC6282] Hui, J., Ed. and P. Thubert, "Compression Format for IPv6 372 Datagrams over IEEE 802.15.4-Based Networks", RFC 6282, 373 DOI 10.17487/RFC6282, September 2011, 374 . 376 [RFC6775] Shelby, Z., Ed., Chakrabarti, S., Nordmark, E., and C. 377 Bormann, "Neighbor Discovery Optimization for IPv6 over 378 Low-Power Wireless Personal Area Networks (6LoWPANs)", RFC 379 6775, DOI 10.17487/RFC6775, November 2012, 380 . 382 [RFC7136] Carpenter, B. and S. Jiang, "Significance of IPv6 383 Interface Identifiers", RFC 7136, DOI 10.17487/RFC7136, 384 February 2014, . 386 7.2. Informative References 388 [fifteendotfour] 389 IEEE Computer Society, "IEEE Std. 802.15.4-2011 IEEE 390 Standard for Local and metropolitan area networks--Part 391 15.4: Low-Rate Wireless Personal Area Networks (LR- 392 WPANs)", June 2011. 394 [I-D.ietf-6man-default-iids] 395 Gont, F., Cooper, A., Thaler, D., and S. LIU, 396 "Recommendation on Stable IPv6 Interface Identifiers", 397 draft-ietf-6man-default-iids-08 (work in progress), 398 October 2015. 400 [IEEE802-2001] 401 Institute of Electrical and Electronics Engineers (IEEE), 402 "IEEE 802-2001 Standard for Local and Metropolitan Area 403 Networks: Overview and Architecture", 2002. 405 [RFC3315] Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins, 406 C., and M. Carney, "Dynamic Host Configuration Protocol 407 for IPv6 (DHCPv6)", RFC 3315, DOI 10.17487/RFC3315, July 408 2003, . 410 [RFC3610] Whiting, D., Housley, R., and N. Ferguson, "Counter with 411 CBC-MAC (CCM)", RFC 3610, DOI 10.17487/RFC3610, September 412 2003, . 414 [RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic 415 Host Configuration Protocol (DHCP) version 6", RFC 3633, 416 DOI 10.17487/RFC3633, December 2003, 417 . 419 [RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)", 420 RFC 3972, DOI 10.17487/RFC3972, March 2005, 421 . 423 [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast 424 Addresses", RFC 4193, DOI 10.17487/RFC4193, October 2005, 425 . 427 [RFC4903] Thaler, D., "Multi-Link Subnet Issues", RFC 4903, DOI 428 10.17487/RFC4903, June 2007, 429 . 431 [RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy 432 Extensions for Stateless Address Autoconfiguration in 433 IPv6", RFC 4941, DOI 10.17487/RFC4941, September 2007, 434 . 436 [RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler, 437 "Transmission of IPv6 Packets over IEEE 802.15.4 438 Networks", RFC 4944, DOI 10.17487/RFC4944, September 2007, 439 . 441 [RFC5535] Bagnulo, M., "Hash-Based Addresses (HBA)", RFC 5535, DOI 442 10.17487/RFC5535, June 2009, 443 . 445 [RFC7217] Gont, F., "A Method for Generating Semantically Opaque 446 Interface Identifiers with IPv6 Stateless Address 447 Autoconfiguration (SLAAC)", RFC 7217, DOI 10.17487/ 448 RFC7217, April 2014, 449 . 451 Authors' Addresses 453 Carles Gomez 454 Universitat Politecnica de Catalunya/Fundacio i2cat 455 C/Esteve Terradas, 7 456 Castelldefels 08860 457 Spain 459 Email: carlesgo@entel.upc.edu 460 Seyed Mahdi Darroudi 461 Universitat Politecnica de Catalunya/Fundacio i2cat 462 C/Esteve Terradas, 7 463 Castelldefels 08860 464 Spain 466 Email: s.darroudi2014@yahoo.com 468 Teemu Savolainen 469 Nokia 470 Visiokatu 3 471 Tampere 33720 472 Finland 474 Email: teemu.savolainen@nokia.com