idnits 2.17.1 draft-ietf-6lowpan-btle-02.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 (August 26, 2011) is 4624 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: 'RFC4861' is mentioned on line 285, but not defined == Missing Reference: 'RFC3610' is mentioned on line 419, but not defined == Unused Reference: 'RFC4994' is defined on line 467, but no explicit reference was found in the text == Outdated reference: A later version (-21) exists of draft-ietf-6lowpan-nd-17 Summary: 0 errors (**), 0 flaws (~~), 5 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 6LoWPAN Working Group J. Nieminen, Ed. 3 Internet-Draft B. Patil 4 Intended status: Standards Track T. Savolainen 5 Expires: February 27, 2012 M. Isomaki 6 Nokia 7 Z. Shelby 8 Sensinode 9 C. Gomez 10 Universitat Politecnica de 11 Catalunya/i2CAT 12 August 26, 2011 14 Transmission of IPv6 Packets over Bluetooth Low Energy 15 draft-ietf-6lowpan-btle-02 17 Abstract 19 Bluetooth Low Energy is a low power air interface technology defined 20 by the Bluetooth Special Interest Group (BT SIG). The standard 21 Bluetooth radio has been widely implemented and available in mobile 22 phones, notebook computers, audio headsets and many other devices. 23 The low power version of Bluetooth is a new specification and enables 24 the use of this air interface with devices such as sensors, smart 25 meters, appliances, etc. The low power variant of Bluetooth is 26 commonly specified in revision 4.0 of the Bluetooth specifications 27 and commonly refered to as Bluetooth 4.0. This document describes 28 how IPv6 is transported over Bluetooth Low Energy using 6LoWPAN 29 techniques. 31 Status of this Memo 33 This Internet-Draft is submitted in full conformance with the 34 provisions of BCP 78 and BCP 79. 36 Internet-Drafts are working documents of the Internet Engineering 37 Task Force (IETF). Note that other groups may also distribute 38 working documents as Internet-Drafts. The list of current Internet- 39 Drafts is at http://datatracker.ietf.org/drafts/current/. 41 Internet-Drafts are draft documents valid for a maximum of six months 42 and may be updated, replaced, or obsoleted by other documents at any 43 time. It is inappropriate to use Internet-Drafts as reference 44 material or to cite them other than as "work in progress." 46 This Internet-Draft will expire on February 27, 2012. 48 Copyright Notice 49 Copyright (c) 2011 IETF Trust and the persons identified as the 50 document authors. All rights reserved. 52 This document is subject to BCP 78 and the IETF Trust's Legal 53 Provisions Relating to IETF Documents 54 (http://trustee.ietf.org/license-info) in effect on the date of 55 publication of this document. Please review these documents 56 carefully, as they describe your rights and restrictions with respect 57 to this document. Code Components extracted from this document must 58 include Simplified BSD License text as described in Section 4.e of 59 the Trust Legal Provisions and are provided without warranty as 60 described in the Simplified BSD License. 62 Table of Contents 64 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 65 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 66 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 67 2. Bluetooth Low Energy . . . . . . . . . . . . . . . . . . . . . 4 68 2.1. Protocol stack . . . . . . . . . . . . . . . . . . . . . . 4 69 2.2. Link layer roles and topology . . . . . . . . . . . . . . 5 70 2.3. LE device addressing . . . . . . . . . . . . . . . . . . . 5 71 2.4. LE packets sizes and MTU . . . . . . . . . . . . . . . . . 5 72 3. Specification of IPv6 over Bluetooth Low Energy . . . . . . . 6 73 3.1. Protocol stack . . . . . . . . . . . . . . . . . . . . . . 6 74 3.2. Link model . . . . . . . . . . . . . . . . . . . . . . . . 7 75 3.2.1. IPv6 Address configuration . . . . . . . . . . . . . . 7 76 3.2.2. Header compression . . . . . . . . . . . . . . . . . . 8 77 3.2.3. Unicast and Multicast address mapping . . . . . . . . 9 78 3.3. Internet connectivity scenarios . . . . . . . . . . . . . 9 79 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 80 5. Security Considerations . . . . . . . . . . . . . . . . . . . 10 81 6. Additional contributors . . . . . . . . . . . . . . . . . . . 10 82 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10 83 8. Normative References . . . . . . . . . . . . . . . . . . . . . 10 84 Appendix A. Bluetooth Low Energy basics . . . . . . . . . . . . . 11 85 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11 87 1. Introduction 89 Bluetooth Low Energy (BT-LE) is a radio technology targeted for 90 devices that operate with coin cell batteries or minimalistic power 91 sources, which means that low power consumption is essential. BT-LE 92 is an especially attractive technology for the Internet of Things 93 applications, such as health monitors, environmental sensing, 94 proximity applications and many others. 96 Considering the expected explosion in the number of sensors and 97 Internet connected devices and things, IPv6 is an ideal protocol due 98 to the large address space it provides. In addition, IPv6 provides 99 tools for autoconfiguration,which is particularly suitable for sensor 100 network applications and nodes which have very limited processing 101 power or a full-fledged operating system. 103 [RFC4944] specifies the transmission of IPv6 over IEEE 802.15.4. The 104 Bluetooth Low Energy link in many respects has similar 105 characteristics to that of IEEE 802.15.4. Many of the mechanisms 106 defined in [RFC4944] can be applied to the transmission of IPv6 on 107 Bluetooth Low Energy links. This document specifies the details of 108 IPv6 transmission over Bluetooth Low Energy links. 110 1.1. Requirements Language 112 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 113 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 114 document are to be interpreted as described in RFC 2119 [RFC2119]. 116 1.2. Terminology 118 Bluetooth Low Energy 120 Bluetooth Low Energy is a low power air interface technology 121 specified by the Bluetooth Special Interest Group (SIG). BT-LE is 122 specified in Revision 4.0 of the Bluetooth specifications (BT 123 4.0). 125 Gateway 127 Network element connecting the BT-LE sensors to the Internet. Can 128 be e.g a home gateway or a mobile device. 130 6LR and 6LBR 132 These terms correspond to those defined in [I-D.ietf-6lowpan-nd] 134 2. Bluetooth Low Energy 136 BT-LE is designed for transferring small amounts of data (in most 137 cases less than 10 bytes) infrequently (e.g. every 500 ms) at modest 138 data rates (e.g. 300 kbps) at a very low cost per bit. 140 BT-LE is an integral part of the BT 4.0 specification. Devices such 141 as mobile phones, notebooks, tablets and other handheld computing 142 devices which will include BT 4.0 chipsets in the near future will 143 have the low-energy functionality of Bluetooth. BT-LE will also be 144 included in many different types of accessories that collaborate with 145 mobile devices such as phones, tablets and notebook computers. An 146 example of a use case for a BT-LE accessory is a heart rate monitor 147 that sends data via the mobile phone to a server on the Internet. 149 2.1. Protocol stack 151 The lower layer of the BT-LE stack consists of the Physical (PHY) and 152 the Link Layer (LL). The Physical Layer transmits and receives the 153 actual packets. The Link Layer is responsible for providing medium 154 access, connection establishment, error control and flow control. 155 The upper layer consists of the Logical Link Control and Adaptation 156 Protocol (L2CAP), Generic Attribute protocol (GATT) and Generic 157 Access Profile (GAP) as shown in Figure 1. GATT and BT-LE profiles 158 together enable the creation of applications in a standardized way 159 without using IP. L2CAP provides multiplexing capability by 160 multiplexing the data channels from the above layers. L2CAP also 161 provides fragmentation and reassembly for large data packets. 163 +----------------------------------------+ 164 | Applications | 165 +----------------------------------------+ 166 | Generic Access Profile | 167 +----------------------------------------+ 168 | Generic Attribute Profile | 169 +----------------------------------------+ 170 | Attribute Protocol |Security Manager | 171 +--------------------+-------------------+ 172 | Logical Link Control and Adaptation | 173 +--------------------+-------------------+ 174 | Host Controller Interface | 175 +--------------------+-------------------+ 176 | Link Layer | Direct Test Mode | 177 +--------------------+-------------------+ 178 | Physical Layer | 179 +--------------------+-------------------+ 180 Figure 1: BT-LE Protocol Stack 182 2.2. Link layer roles and topology 184 BT-LE defines two Link Layer roles: the Master Role and the Slave 185 Role. A device in the Master Role, which is called master, can 186 manage multiple simultaneous connections with a number of devices in 187 the Slave Role, called slaves. A slave can only be connected to a 188 single master. Hence, a BT-LE network (i.e. a BT-LE piconet) follows 189 a star topology. 191 [BTLE-Slave]-----\ /-----[BTLE-Slave] 192 \ / 193 [BTLE-Slave]-----/[BTLE-Master]/-----[BTLE-Slave] 194 / \ 195 [BTLE-Slave]-----/ \-----[BTLE-Slave] 197 Figure 2: BT-LE Star Topology 199 A master is assumed to be less constrained than a slave. Hence, 200 master and slave can correspond with 6LoWPAN Border Router (6LBR) and 201 host, respectively. 203 In BT-LE, communication only takes place between a master and a 204 slave. Hence, in a BT-LE network using IP, a radio hop is equivalent 205 to an IP link and vice versa. 207 2.3. LE device addressing 209 Every LE device is identified by a unique 48 bit Bluetooth Device 210 Address (BD_ADDR). An LE-only device such as a sensor may use a 211 public (obtained from IEEE Registration Authority) or a random device 212 address (generated internally). When LE devices are in a connection 213 they are addressed by an Access Address, a 32 bit address generated 214 at the time of the connection set up. The access address identifies 215 a connection between a slave and a master. 217 2.4. LE packets sizes and MTU 219 Maximum size of the payload in an LE packet at the baseband is 31 220 bytes which means that at the L2CAP layer this equals to 23 octets 221 MTU. For power efficient communication between a sensor and a client 222 the sensor data and its header should fit in 23 octet payload. MTU 223 longer than 23 octets can be supported by the LE specification. 225 3. Specification of IPv6 over Bluetooth Low Energy 227 BT-LE technology sets strict requirements for low power consumption 228 and thus limits the allowed protocol overhead. 6LoWPAN standard 229 [RFC4944], [I-D.ietf-6lowpan-nd] and [I-D.ietf-6lowpan-hc] provides 230 useful generic functionality like header compression, link-local IPv6 231 addresses, Neighbor Discovery and stateless IP-address 232 autoconfiguration for reducing the overhead in 802.15.4 networks. 233 This functionality can be partly applied to BT-LE. 235 A significant difference between IEEE 802.15.4 and BT-LE is that the 236 former supports the mesh topology (and requires a routing protocol), 237 whereas BT-LE does not currently support the formation of multihop 238 networks. In consequence, the mesh header defined in [RFC4944] for 239 mesh under routing MUST NOT be used in BT-LE networks. On the other 240 hand, a BT-LE device MUST NOT play the role of a 6LoWPAN Router 241 (6LR). 243 When BT-LE is applied in sensors, generated data may fit into one 244 Link Layer packet (23 bytes, maximum L2CAP payload size) that is 245 transferred to the collector device periodically. However, IP data 246 packets may be much larger and hence MTU size should be the size of 247 the IP data packet. Segmentation and reassembly (SAR) functionality 248 is an inherent function of the BT-LE link layer. Larger L2CAP 249 packets can be transferred with the assistance of the SAR 250 functionality provided by the link layer. This specification 251 requires that SAR functionality MUST be provided in the link layer up 252 to the IPv6 minimum MTU of 1280 bytes. Since SAR functionality in 253 BT-LE is a function of the link layer, fragmentation functionality as 254 defined in [RFC4944] SHOULD NOT be used in BT-LE neworks. 256 3.1. Protocol stack 258 In order to enable transmission of IPv6 packets over BT-LE, a new 259 fixed L2CAP channel ID MUST be reserved for IPv6 traffic by the BT- 260 SIG. A request for allocation of a new fixed channel ID for IPv6 261 traffic by the BT-SIG should be submitted through the liaison process 262 or formal communique from the 6lowpan chairs and respective area 263 directors. This specification defines the use of channel ID 0x07 for 264 this purpose. Figure 3 illustrates IPv6 over BT-LE stack. 266 +-------------------+ 267 | UDP/TCP | 268 +-------------------+ 269 | IPv6 over BT-LE | 270 +-------------------+ 271 | BT-LE L2CAP | 272 +-------------------+ 273 | BT-LE Link Layer | 274 +-------------------+ 275 | BT-LE Physical | 276 +-------------------+ 278 Figure 3: IPv6 over BT-LE Stack 280 3.2. Link model 282 The concept of IP link (layer 3) and the physical link (combination 283 of PHY and MAC) needs to be clear and the relation well understood in 284 order to specify the addressing scheme for transmitting IPv6 packets 285 over the BT-LE link. [RFC4861] defines a link as "a communication 286 facility or medium over which nodes can communicate at the link 287 layer, i.e., the layer immediately below IP." 289 In the case of BT-LE, L2CAP is an adaptation layer that supports the 290 transmission of IPv6 packets. L2CAP also provides multiplexing 291 capability in addition to SAR functionality. 293 The BT-LE link between two communicating nodes can be considered to 294 be a point-to-point or point-to-multipoint link. When one of the 295 communicating nodes is in the role of a master, then the link can be 296 viewed as a point-to-multipoint link. 298 When a host connects to another BT-LE device the link is up and IP 299 address configuration and transmission can occur. 301 3.2.1. IPv6 Address configuration 303 The Interface Identifier (IID) for a BT-LE interface MUST be formed 304 from the 48-bit public device Bluetooth address as per the "IPv6 over 305 Ethernet" specification [RFC2464]. An IPv6 prefix used for stateless 306 autoconfiguration [RFC4862] of a BT-LE interface MUST have a length 307 of 64 bits. 309 The IPv6 link-local address [RFC4291] for a BT-LE interface is formed 310 by appending the IID, as defined above, to the prefix FE80::/64, as 311 depicted in Figure 4. 313 10 bits 54 bits 64 bits 314 +----------+-----------------+----------------------+ 315 |1111111010| zeros | Interface Identifier | 316 +----------+-----------------+----------------------+ 318 Figure 4: IPv6 link-local address in BT-LE 320 3.2.2. Header compression 322 This document assumes [I-D.ietf-6lowpan-hc], which specifies the 323 compression format for IPv6 datagrams on top of IEEE 802.15.4, as the 324 basis for IPv6 header compression on top of BT-LE. However, whereas 325 IEEE 802.15.4 frames contain source and destination MAC layer 326 addresses, BT-LE data channel PDUs contain the Access Address, which 327 identifies the connection between a master and a slave. The 328 following text describes the principles of IPv6 address compression 329 on top of BT-LE. 331 In a link-local communication, both the IPv6 source and destination 332 addresses can be elided. In fact, the node that receives a data 333 channel PDU through a Link Layer connection MAY infer that the IPv6 334 destination address of the packet is its own IPv6 address. If a node 335 knows the IID of the other endpoint of the Link Layer connection, the 336 IPv6 source address MAY also be elided. A device MAY learn the IID 337 of the other endpoint of a Link Layer connection e.g. from the RS/RA/ 338 NS/NA Neighbor Discovery (ND) message exchange. The device MAY 339 maintain a Neighbor Cache, in which the entries include both the IID 340 of the neighbor and the Access Address that identifies the Link Layer 341 connection with the neighbor. A device MAY also derive the IID of 342 the other endpoint of a Link Layer connection from the Link Layer 343 connection establishment messages. The device MAY maintain a 344 Neighbor Cache, in which the entries include both the IID of the 345 neighbor and the Access Address that identifies the Link Layer 346 connection with the neighbor. 348 When a BT-LE slave transmits an IPv6 packet to a remote destination 349 using global IPv6 addresses, the slave MAY elide the IPv6 source 350 address. This is possible since 1) the master/6LBR has previously 351 assigned the prefix to the slaves; and 2) the master/6LBR maintains a 352 Neighbor Cache that relates the Access Address of each Link Layer 353 connection and the IID of the corresponding slave. The slave MAY 354 also elide the prefix of the destination IPv6 address if a context is 355 defined for the IPv6 destination address. 357 When a master/6LBR receives an IPv6 packet sent by a remote node 358 outside the BT-LE network, and the destination of the packet is a 359 slave, the master/6LBR MAY elide the IID of the IPv6 destination 360 address by exploiting the information contained in the table 361 mentioned above. The prefixes of the IPv6 destination and source 362 addresses MAY also be elided if a context is defined for them. 364 3.2.3. Unicast and Multicast address mapping 366 In BT-LE, address resolution should be used for finding the Access 367 Address of the Link Layer connection with the target node. The BT-LE 368 link layer does not support multicast. Hence traffic is always 369 unicast between two BT-LE devices. Even in the case where a master 370 is attached to multiple slave BT-LE devices, the master device cannot 371 do a multicast to all the connected slave devices. If the master 372 device needs to send a multicast packet to all its slave devices, it 373 has to replicate the packet and unicast it on each link. However, 374 this may not be energy-efficient and particular care must be taken if 375 the master is battery-powered. In the opposite direction, a slave 376 can only transmit data to a single destination (i.e. the master). 377 Hence, if a slave transmits an IPv6 multicast packet, the slave can 378 unicast the corresponding BT-LE packet to the master. There should 379 be a table for mapping different types of multicast addresses to the 380 access address in the master. 382 3.3. Internet connectivity scenarios 384 In a typical scenario, BT-LE network is connected to the Internet. 386 h ____________ 387 \ / \ 388 h ---- 6LBR --- | Internet | 389 / \____________/ 390 h 391 h: host 392 <-- BT-LE --> 6LBR: 6LoWPAN Border Router 394 Figure 5: BT-LE network connected to the Internet 396 In some scenarios, the BT-LE network may transiently or permanently 397 be an isolated network. 399 h h h: host 400 \ / 6LBR: 6LoWPAN Border Router 401 h --- 6LBR -- h 402 / \ 403 h h 405 Figure 6: Isolated BT-LE network 407 4. IANA Considerations 409 While there are no actions for IANA, we do expect BT SIG to allocate 410 an L2CAP channel ID. 412 5. Security Considerations 414 The transmission of IPv6 over BT-LE links has similar requirements 415 and concerns for security as for IEEE 802.15.4. IPv6 over BT-LE 416 SHOULD be protected by using BT-LE Link Layer security. 418 BT-LE Link Layer supports encryption and authentication by using the 419 Counter with CBC-MAC (CCM) mechanism [RFC3610] and a 128-bit AES 420 block cipher. Upper layer security mechanisms may exploit this 421 functionality when it is available. (Note: CCM does not consume 422 bytes from the maximum per-packet L2CAP data size, since the link 423 layer data unit has a specific field for them when they are used.) 425 Key management in BT-LE is provided by the Security Manager Protocol 426 (SMP). 428 6. Additional contributors 430 Kanji Kerai, Jari Mutikainen, David Canfeng-Chen and Minjun Xi from 431 Nokia have contributed significantly to this document. 433 7. Acknowledgements 435 Erik Nordmark has provided valuable feedback for this draft. 437 8. Normative References 439 [I-D.ietf-6lowpan-hc] 440 Hui, J. and P. Thubert, "Compression Format for IPv6 441 Datagrams in Low Power and Lossy Networks (6LoWPAN)", 442 draft-ietf-6lowpan-hc-15 (work in progress), 443 February 2011. 445 [I-D.ietf-6lowpan-nd] 446 Shelby, Z., Chakrabarti, S., and E. Nordmark, "Neighbor 447 Discovery Optimization for Low Power and Lossy Networks 448 (6LoWPAN)", draft-ietf-6lowpan-nd-17 (work in progress), 449 June 2011. 451 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 452 Requirement Levels", BCP 14, RFC 2119, March 1997. 454 [RFC2464] Crawford, M., "Transmission of IPv6 Packets over Ethernet 455 Networks", RFC 2464, December 1998. 457 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 458 Architecture", RFC 4291, February 2006. 460 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 461 Address Autoconfiguration", RFC 4862, September 2007. 463 [RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler, 464 "Transmission of IPv6 Packets over IEEE 802.15.4 465 Networks", RFC 4944, September 2007. 467 [RFC4994] Zeng, S., Volz, B., Kinnear, K., and J. Brzozowski, 468 "DHCPv6 Relay Agent Echo Request Option", RFC 4994, 469 September 2007. 471 Appendix A. Bluetooth Low Energy basics 473 This section will provide background material on the basics of 474 bluetooth low energy. 476 Authors' Addresses 478 Johanna Nieminen (editor) 479 Nokia 480 Itaemerenkatu 11-13 481 FI-00180 Helsinki 482 Finland 484 Email: johanna.1.nieminen@nokia.com 485 Basavaraj Patil 486 Nokia 487 6021 Connection drive 488 Irving, TX 75039 489 USA 491 Email: basavaraj.patil@nokia.com 493 Teemu Savolainen 494 Nokia 495 Hermiankatu 12 D 496 FI-33720 Tampere 497 Finland 499 Email: teemu.savolainen@nokia.com 501 Markus Isomaki 502 Nokia 503 Keilalahdentie 2-4 504 FI-02150 Espoo 505 Finland 507 Email: markus.isomaki@nokia.com 509 Zach Shelby 510 Sensinode 511 Hallituskatu 13-17D 512 FI-90100 Oulu 513 Finland 515 Email: zach.shelby@sensinode.com 517 Carles Gomez 518 Universitat Politecnica de Catalunya/i2CAT 519 C/Esteve Terradas, 7 520 Castelldefels 08860 521 Spain 523 Email: carlesgo@entel.upc.edu