idnits 2.17.1 draft-ietf-6lowpan-btle-01.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 (July 1, 2011) is 4681 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-6lowpan-hc' is defined on line 364, but no explicit reference was found in the text == Unused Reference: 'RFC4994' is defined on line 392, 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 (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 6LoWPAN Working Group J. Nieminen, Ed. 2 Internet-Draft B. Patil 3 Intended status: Standards Track T. Savolainen 4 Expires: January 2, 2012 M. Isomaki 5 Nokia 6 Z. Shelby 7 Sensinode 8 C. Gomez 9 Universitat Politecnica de 10 Catalunya/i2CAT 11 July 1, 2011 13 Transmission of IPv6 Packets over Bluetooth Low Energy 14 draft-ietf-6lowpan-btle-01 16 Abstract 18 Bluetooth Low Energy is a low power air interface technology defined 19 by the Bluetooth Special Interest Group (BT SIG). The standard 20 Bluetooth radio has been widely implemented and available in mobile 21 phones, notebook computers, audio headsets and many other devices. 22 The low power version of Bluetooth is a new specification and enables 23 the use of this air interface with devices such as sensors, smart 24 meters, appliances, etc. The low power variant of Bluetooth is 25 commonly specified in revision 4.0 of the bluetooth specifications 26 and commonly refered to as bluetooth 4.0. This document describes 27 how IPv6 is transported over Bluetooth Low Energy using 6LoWPAN 28 techniques. 30 Status of this Memo 32 This Internet-Draft is submitted in full conformance with the 33 provisions of BCP 78 and BCP 79. 35 Internet-Drafts are working documents of the Internet Engineering 36 Task Force (IETF). Note that other groups may also distribute 37 working documents as Internet-Drafts. The list of current Internet- 38 Drafts is at http://datatracker.ietf.org/drafts/current/. 40 Internet-Drafts are draft documents valid for a maximum of six months 41 and may be updated, replaced, or obsoleted by other documents at any 42 time. It is inappropriate to use Internet-Drafts as reference 43 material or to cite them other than as "work in progress." 45 This Internet-Draft will expire on January 2, 2012. 47 Copyright Notice 48 Copyright (c) 2011 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (http://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with respect 56 to this document. Code Components extracted from this document must 57 include Simplified BSD License text as described in Section 4.e of 58 the Trust Legal Provisions and are provided without warranty as 59 described in the Simplified BSD License. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 64 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 65 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 66 2. Bluetooth Low Energy . . . . . . . . . . . . . . . . . . . . . 4 67 2.1. Protocol stack . . . . . . . . . . . . . . . . . . . . . . 4 68 2.2. Link layer roles and topology . . . . . . . . . . . . . . 5 69 3. Specificaion of IPv6 over Bluetooth Low Energy . . . . . . . . 5 70 3.1. Protocol stack . . . . . . . . . . . . . . . . . . . . . . 6 71 3.2. Link model . . . . . . . . . . . . . . . . . . . . . . . . 6 72 3.2.1. IPv6 Address configuration . . . . . . . . . . . . . . 6 73 3.2.2. Unicast and Multicast address mapping . . . . . . . . 7 74 3.3. Internet connectivity scenarios . . . . . . . . . . . . . 8 75 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 76 5. Security Considerations . . . . . . . . . . . . . . . . . . . 8 77 6. Additional contributors . . . . . . . . . . . . . . . . . . . 9 78 7. Normative References . . . . . . . . . . . . . . . . . . . . . 9 79 Appendix A. Bluetooth Low Energy basics . . . . . . . . . . . . . 10 80 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10 82 1. Introduction 84 Bluetooth Low Energy (BT-LE) is a radio technology targeted for 85 devices that operate with coin cell batteries or minimalistic power 86 sources, which means that low power consumption is essential. BT-LE 87 is an especially attractive technology for the Internet of Things 88 applications, such as health monitors, environmental sensing, 89 proximity applications and many others. 91 Considering the expected explosion in the number of sensors and 92 Internet connected devices and things, IPv6 is an ideal protocol due 93 to the large address space it provides. In addition, IPv6 provides 94 tools for autoconfiguration,which is particularly suitable for sensor 95 network applications and nodes which have very limited processing 96 power or a full-fledged operating system. 98 [RFC4944] specifies the transmission of IPv6 over IEEE 802.15.4. The 99 Bluetooth Low Energy link in many respects has similar 100 characteristics to that of IEEE 802.15.4. Many of the mechanisms 101 defined in [RFC4944] can be applied to the transmission of IPv6 on 102 Bluetooth Low Energy links. This document specifies the details of 103 IPv6 transmission over Bluetooth Low Energy links. 105 1.1. Requirements Language 107 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 108 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 109 document are to be interpreted as described in RFC 2119 [RFC2119]. 111 1.2. Terminology 113 Bluetooth Low Energy 115 Bluetooth low energy is a low power air interface technology 116 specified by the Bluetooth Special Interest Group (SIG). BT-LE is 117 specified in Revision 4.0 of the bluetooth specifications. 119 Gateway 121 Network element connecting the BT-LE sensors to the Internet. Can 122 be e.g a home gateway or a mobile device. 124 6LR and 6LBR 126 These terms correspond to those defined in [I-D.ietf-6lowpan-nd] 128 2. Bluetooth Low Energy 130 BT-LE is designed for transferring small amounts of data (in most 131 cases less than 10 bytes) infrequently (e.g. every 500 ms) at modest 132 data rates (e.g. 300 kbps) at a very low cost per bit. 134 BT-LE is an integral part of the BT4.0 specification. Devices such 135 as mobile phones, notebooks, tablets and other handheld computing 136 devices which will include BT4.0 chipsets in the near future will 137 have the low-energy functionality of bluetooth. BT-LE will also be 138 included in many different types of accessories that collaborate with 139 mobile devices such as phones, tablets and notebook computers. An 140 example of a use case for a BT-LE accessory is a heart rate monitor 141 that sends data via the mobile phone to a server on the Internet. 143 2.1. Protocol stack 145 The lower layer of the BT-LE stack consists of the Physical (PHY) and 146 the Link Layer (LL). Link Layer is responsible for managing the 147 channels and Physical Layer transmits and receives the actual 148 packets. The upper layer consists of the Logical Link Control and 149 Adaptation Protocol (L2CAP), Generic Attribute protocol (GATT) and 150 Generic Attribute profile (GAP) as shown in Figure 1. GATT and BT-LE 151 profiles together enable the creation of applications in a 152 standardized way without using IP. L2CAP provides multiplexing 153 capability by multiplexing the data channels from the above layers. 154 L2CAP also provides fragmentation and reassembly for larger data 155 packets. 157 +----------------------------------------+ 158 | Applications | 159 +----------------------------------------+ 160 | Generic Access Profile | 161 +----------------------------------------+ 162 | Generic Attribute Profile | 163 +----------------------------------------+ 164 | Attribute Protocol |Security Manager | 165 +--------------------+-------------------+ 166 | Logical Link Control and Adaptation | 167 +--------------------+-------------------+ 168 | Host Controller Interface | 169 +--------------------+-------------------+ 170 | Link Layer | Direct Test Mode | 171 +--------------------+-------------------+ 172 | Physical Layer | 173 +--------------------+-------------------+ 174 Figure 1: BT-LE Protocol Stack 176 2.2. Link layer roles and topology 178 BT-LE defines two Link Layer roles: the Master Role and the Slave 179 Role. A device in the Master Role, which is called master, can 180 manage multiple simultaneous connections with a number of devices in 181 the Slave Role, called slaves. A slave can only be connected to a 182 single master. Hence, a BT-LE network (i.e. a BT-LE piconet) follows 183 a star topology. 185 A master is assumed to be less constrained than a slave. Hence, 186 master and slave can correspond with 6LoWPAN Border Router (6LBR) and 187 host, respectively. 189 In BT-LE, communication only takes place between a master and a 190 slave. Hence, in a BT-LE network using IP, a radio hop is equivalent 191 to an IP link and vice versa. 193 3. Specificaion of IPv6 over Bluetooth Low Energy 195 BT-LE technology sets strict requirements for low power consumption 196 and thus limits the allowed protocol overhead. 6LoWPAN standard 197 [RFC4944] provides useful generic functionality like header 198 compression, link-local IPv6 addresses, Neighbor Discovery and 199 stateless IP-address autoconfiguration for reducing the overhead in 200 802.15.4 networks. This functionality can be partly applied to 201 BT-LE. 203 A significant difference between IEEE 802.15.4 and BT-LE is that the 204 former supports the mesh topology (and requires a routing protocol), 205 whereas BT-LE does not currently support the formation of multihop 206 networks. In consequence, the mesh header defined in [RFC4944] for 207 mesh under routing SHOULD NOT be used in BT-LE networks. On the 208 other hand, a BT-LE device MUST NOT play the role of a 6LoWPAN 209 Router. 211 When BT-LE is applied in sensors, generated data usually fits into 212 one Link Layer packet (23 bytes, maximum L2CAP payload size) that is 213 transferred to the collector device periodically. IP data packets 214 may be much larger and hence MTU size should be the size of the IP 215 data packet. Larger L2CAP packets can be transferred with the 216 Segmentation And Reassembly (SAR) feature of the Link Layer. This 217 specification requires that SAR functionality MUST be provided in the 218 Link Layer up to the IPv6 MTU of 1280 bytes. Therefore, the 6LoWPAN 219 fragmentation functinoality defined in [RFC4944] SHOULD NOT be used 220 in BT-LE neworks. 222 3.1. Protocol stack 224 In order to enable transmission of IPv6 packets over BT-LE, a new 225 fixed channel ID SHOULD be reserved for IPv6 traffic in the BT-SIG. 226 This specification defines the use of channel ID 0x07 for this 227 purpose. Figure 2 illustrates IPv6 over BT-LE stack. 229 +-------------------+ 230 | UDP/TCP | 231 +-------------------+ 232 | IPv6 | 233 +-------------------+ 234 | 6LoWPAN | 235 +-------------------+ 236 | BT-LE L2CAP | 237 +-------------------+ 238 | BT-LE Link Layer | 239 +-------------------+ 240 | BT-LE Physical | 241 +-------------------+ 243 Figure 2: IPv6 over BT-LE Stack 245 3.2. Link model 247 3.2.1. IPv6 Address configuration 249 The Interface Identifier for a BT-LE interface MUST be formed from 250 the 48-bit public device Bluetooth address as per the "IPv6 over 251 Ethernet" specification [RFC2464]. An IPv6 prefix used for stateless 252 autoconfiguration [RFC4862] of a BT-LE interface MUST have a length 253 of 64 bits. 255 The IPv6 link-local address [RFC4291] for a BT-LE interface is formed 256 by appending the Interface Identifier, as defined above, to the 257 prefix FE80::/64, as depicted in Figure 3. 259 10 bits 54 bits 64 bits 260 +----------+-----------------+----------------------+ 261 |1111111010| zeros | Interface Identifier | 262 +----------+-----------------+----------------------+ 264 Figure 3: IPv6 link-local address in BT-LE 266 In a link-local communication, both the IPv6 source and destination 267 addresses can be elided. In fact, the node that receives a data 268 channel PDU through a Link Layer connection MAY infer that the IPv6 269 destination address of the packet is its own IPv6 address. If a node 270 knows the IID of the other endpoint of the Link Layer connection, the 271 IPv6 source address MAY also be elided. A device MAY learn the IID 272 of the other endpoint of a Link Layer connection e.g. from the RS/RA/ 273 NS/NA Neighbor Discovery (ND) message exchange. The device MAY 274 maintain a Neighbor Cache, in which the entries include both the IID 275 of the neighbor and the Access Address that identifies the Link Layer 276 connection with the neighbor. A device MAY also derive the IID of 277 the other endpoint of a Link Layer connection from the Link Layer 278 connection establishment messages. 280 When a BT-LE slave transmits an IPv6 packet to a remote destination 281 using global IPv6 addresses, the slave MAY elide the IPv6 source 282 address. This is possible since 1) the master/6LBR has previously 283 assigned the prefix to the slaves; and 2) the master/6LBR maintains a 284 Neighbor Cache that relates the Access Address of each Link Layer 285 connection and the Interface Identifier of the corresponding slave. 286 The slave MAY also elide the prefix of the destination IPv6 address 287 if a context is defined for the IPv6 destination address. 289 When a master/6LBR receives an IPv6 packet sent by a remote node 290 outside the BT-LE network, and the destination of the packet is a 291 slave, the master/6LBR MAY elide the Interface Identifier of the IPv6 292 destination address by exploiting the information contained in the 293 table mentioned above. The prefixes of the IPv6 destination and 294 source addresses MAY also be elided if a context is defined for them. 296 3.2.2. Unicast and Multicast address mapping 298 In BT-LE, address resolution should be used for finding the Access 299 Address of the LL connection with the target node. The master cannot 300 simultaneously transmit a packet to multiple slaves (each slave 301 listens at different times). One option is: when a master has to 302 transmit an IPv6 multicast packet, it unicasts the corresponding 303 BT-LE packet to each of its slaves. However, if the master is 304 battery-powered, this may not be energy-efficient. In the opposite 305 direction, a slave can only transmit data to a single destination 306 (i.e. the master). Hence, if a slave transmits an IPv6 multicast 307 packet, the slave can unicast the corresponding BT-LE packet to the 308 master. 310 3.3. Internet connectivity scenarios 312 In a typical scenario, BT-LE network is connected to the Internet. 314 h ____________ 315 \ / \ 316 h ---- 6LBR --- | Internet | 317 / \____________/ 318 h 319 h: host 320 <-- BT-LE --> 6LBR: 6LoWPAN Border Router 322 Figure 4: BT-LE network connected to the Internet 324 In some scenarios, the BT-LE network may transiently or permanently 325 be an isolated network. 327 h h h: host 328 \ / 6LBR: 6LoWPAN Border Router 329 h --- 6LBR -- h 330 / \ 331 h h 333 Figure 5: Isolated BT-LE network 335 4. IANA Considerations 337 This document does not have any IANA requests at this time. This may 338 change with further development of the specification. 340 5. Security Considerations 342 The transmission of IPv6 over bluetooth low energy links has similar 343 requirements and concerns for security as for IEEE 802.15.4. 344 Security at the IP layer needs to be reviewed as part of the 345 development of the IPv6 over Bluetooth Low Energy specification. 347 BT-LE Link Layer supports encryption and authentication by using the 348 CCM mechanism and a 128-bit AES block cipher. Upper layer security 349 mechanisms may exploit this functionality when it is available. 350 (Note: CCM does not consume bytes from the maximum per-packet L2CAP 351 data size, since the link layer data unit has a specific field for 352 them when they are used.) 354 Key management in BT-LE is provided by the Security Manager Protocol 355 (SMP). 357 6. Additional contributors 359 Kanji Kerai, Jari Mutikainen,David Canfeng-Chen and Minjun Xi from 360 Nokia have contributed significantly to this document. 362 7. Normative References 364 [I-D.ietf-6lowpan-hc] 365 Hui, J. and P. Thubert, "Compression Format for IPv6 366 Datagrams in Low Power and Lossy Networks (6LoWPAN)", 367 draft-ietf-6lowpan-hc-15 (work in progress), 368 February 2011. 370 [I-D.ietf-6lowpan-nd] 371 Shelby, Z., Chakrabarti, S., and E. Nordmark, "Neighbor 372 Discovery Optimization for Low Power and Lossy Networks 373 (6LoWPAN)", draft-ietf-6lowpan-nd-17 (work in progress), 374 June 2011. 376 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 377 Requirement Levels", BCP 14, RFC 2119, March 1997. 379 [RFC2464] Crawford, M., "Transmission of IPv6 Packets over Ethernet 380 Networks", RFC 2464, December 1998. 382 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 383 Architecture", RFC 4291, February 2006. 385 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 386 Address Autoconfiguration", RFC 4862, September 2007. 388 [RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler, 389 "Transmission of IPv6 Packets over IEEE 802.15.4 390 Networks", RFC 4944, September 2007. 392 [RFC4994] Zeng, S., Volz, B., Kinnear, K., and J. Brzozowski, 393 "DHCPv6 Relay Agent Echo Request Option", RFC 4994, 394 September 2007. 396 Appendix A. Bluetooth Low Energy basics 398 This section will provide background material on the basics of 399 bluetooth low energy. 401 Authors' Addresses 403 Johanna Nieminen (editor) 404 Nokia 405 Itaemerenkatu 11-13 406 FI-00180 Helsinki 407 Finland 409 Email: johanna.1.nieminen@nokia.com 411 Basavaraj Patil 412 Nokia 413 6021 Connection drive 414 Irving, TX 75039 415 USA 417 Email: basavaraj.patil@nokia.com 419 Teemu Savolainen 420 Nokia 421 Hermiankatu 12 D 422 FI-33720 Tampere 423 Finland 425 Email: teemu.savolainen@nokia.com 427 Markus Isomaki 428 Nokia 429 Keilalahdentie 2-4 430 FI-02150 Espoo 431 Finland 433 Email: markus.isomaki@nokia.com 434 Zach Shelby 435 Sensinode 436 Hallituskatu 13-17D 437 FI-90100 Oulu 438 Finland 440 Email: zach.shelby@sensinode.com 442 Carles Gomez 443 Universitat Politecnica de Catalunya/i2CAT 444 C/Esteve Terradas, 7 445 Castelldefels 08860 446 Spain 448 Email: carlesgo@entel.upc.edu