idnits 2.17.1 draft-ietf-6lowpan-btle-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 == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'SHOULD not' in this paragraph: In [RFC4944] different types of frame formats and related headers have been defined to support fragmentation and mesh addressing. In BT-LE context latest version of LoWPAN compressed IPv6 header SHOULD be used by default. Support for fragmentation and mesh headers MAY be added. However, since BT-LE operates on a star topology, mesh headers SHOULD not be required. In BT-LE link with header compression IPv6 header (originally 40 Bytes) can be compressed to only 2 Bytes with link-local addresses and 26 Bytes with Global addresses. UDP header (originally 8 Bytes) can be compressed to 4 Bytes. -- The document date (April 19, 2011) is 4748 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: 'RFC4994' is defined on line 482, but no explicit reference was found in the text == Outdated reference: A later version (-21) exists of draft-ietf-6lowpan-nd-15 Summary: 0 errors (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Individual Submission J. Nieminen, Ed. 3 Internet-Draft B. Patil 4 Intended status: Standards Track T. Savolainen 5 Expires: October 22, 2011 M. Isomaki 6 Nokia 7 Z. Shelby 8 Sensinode 9 C. Gomez 10 Universitat Politecnica de 11 Catalunya/i2CAT 12 April 19, 2011 14 Transmission of IPv6 Packets over Bluetooth Low Energy 15 draft-ietf-6lowpan-btle-00 17 Abstract 19 Bluetooth Low Energy is a low power air interface technology that is 20 defined by the Bluetooth SIG. The standard Bluetooth radio has been 21 widely implemented and available in mobile phones, notebook 22 computers, audio headsets and many other devices. The low power 23 version of Bluetooth is a new specification and enables the use of 24 this air interface with devices such as sensors, smart meters, 25 appliances, etc. There is an added value in the ability to 26 communicate with sensors over IPv6. This document describes how IPv6 27 is transported over Bluetooth Low Energy using 6LoWPAN techniques. 29 Status of this Memo 31 This Internet-Draft is submitted in full conformance with the 32 provisions of BCP 78 and BCP 79. 34 Internet-Drafts are working documents of the Internet Engineering 35 Task Force (IETF). Note that other groups may also distribute 36 working documents as Internet-Drafts. The list of current Internet- 37 Drafts is at http://datatracker.ietf.org/drafts/current/. 39 Internet-Drafts are draft documents valid for a maximum of six months 40 and may be updated, replaced, or obsoleted by other documents at any 41 time. It is inappropriate to use Internet-Drafts as reference 42 material or to cite them other than as "work in progress." 44 This Internet-Draft will expire on October 22, 2011. 46 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 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3 65 2.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 66 3. Bluetooth Low Energy protocol stack . . . . . . . . . . . . . 4 67 3.1. Support for IPv6 over BT-LE . . . . . . . . . . . . . . . 5 68 4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 6 69 5. Bluetooth Low Energy roles and network topology . . . . . . . 6 70 6. BT-LE network connectivity scenarios . . . . . . . . . . . . . 6 71 7. Addressing Model . . . . . . . . . . . . . . . . . . . . . . . 7 72 8. MTU Issues . . . . . . . . . . . . . . . . . . . . . . . . . . 8 73 9. LoWPAN Adaptation for BT-LE and frame format . . . . . . . . . 8 74 10. IPv6 Address configuration . . . . . . . . . . . . . . . . . . 8 75 11. IPv6 LLA in BLE . . . . . . . . . . . . . . . . . . . . . . . 8 76 12. Unicast and Multicast address mapping . . . . . . . . . . . . 9 77 13. Header compression . . . . . . . . . . . . . . . . . . . . . . 9 78 14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 79 15. Security Considerations . . . . . . . . . . . . . . . . . . . 10 80 16. Additional contributors . . . . . . . . . . . . . . . . . . . 11 81 17. Normative References . . . . . . . . . . . . . . . . . . . . . 11 82 Appendix A. Bluetooth Low Energy basics . . . . . . . . . . . . . 12 83 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 85 1. Introduction 87 Bluetooth Low Energy (BT-LE) is a radio technology targeted for 88 devices that operate with coin cell batteries, which means that low 89 power consumption is essential. BT-LE can also be integrated into 90 existing Bluetooth (BT) devices so that devices such as mobile phones 91 and PCs can operate with existing BT accessories as well as BT-LE 92 accessories. An example of a use case for a BT-LE accessory is a 93 heart rate monitor that sends data via the mobile phone to a server 94 on the Internet. BT-LE is designed for transferring small amount of 95 data (in most cases less than 10 bytes) less frequently (e.g. every 96 500 ms) at modest data rates (e.g. 300 kbps). BT-LE enables low cost 97 sensors to send their data over the Internet via a gateway such as a 98 mobile phone. BT-LE is an especially attractive technology for 99 Internet of Things applications, such as health monitors, 100 environmental sensing and proximity applications. 102 Considering the expected explosion in the number of sensors, IPv6 is 103 an ideal protocol due to the large address space it provides. In 104 addition, IPv6 provides tools for autoconfiguration and unattended 105 operation, which are particularly suitable for sensor network 106 applications. This document describes how IPv6 is used on Bluetooth 107 Low Energy links in a power efficient manner along with efficient 108 application protocols that enable the integration of BT-LE devices 109 into services. 111 [RFC4944] specifies the transmission of IPv6 over IEEE 802.15.4. The 112 Bluetooth Low Energy link in many respects has similar 113 characteristics to that of IEEE 802.15.4. Many of the mechanisms 114 defined in [RFC4944] can be applied to the transmission of IPv6 on 115 Bluetooth Low Energy links. This document specifies the details of 116 IPv6 transmission over Bluetooth Low Energy links. 118 2. Requirements Language 120 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 121 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 122 document are to be interpreted as described in RFC 2119 [RFC2119]. 124 2.1. Terminology 126 Bluetooth Low Energy 128 Bluetooth low energy is a low power air interface technology 129 specified by the Bluetooth Special Interest Group (SIG). 131 Gateway 133 Network element connecting the BT-LE sensors to the Internet. Can 134 be e.g a home gateway or a mobile device. 136 ND-Proxy 138 A gateway that operates as a proxy for IPv6 neighbor discovery 140 3. Bluetooth Low Energy protocol stack 142 Bluetooth Low Energy is a low power wireless technology developed by 143 the BT-SIG. The lower layer of the BT-LE stack consists of the RF 144 and the Link layer which are implemented in the BT-LE controller. 145 The upper layer consists of the Logical Link Control and Adaptation 146 Protocol (L2CAP), Generic Attribute protocol (GATT) and Generic 147 Attribute profile (GAP) as shown in Figure 1. GATT and BT-LE 148 profiles together enable the creation of applications in a 149 standardized way without using IP. L2CAP provides multiplexing 150 capability by multiplexing the data channels from the above layers. 151 L2CAP also provides fragmentation and reassembly for larger data 152 packets. Link Layer (LL) is responsible for managing the channels 153 and Physical Layer (PHY) transmits and receives the actual packets. 155 +----------------------------------------+ 156 | Applications | 157 +----------------------------------------+ 158 | Generic Access Profile | 159 +----------------------------------------+ 160 | Generic Attribute Profile | 161 +----------------------------------------+ 162 | Attribute Protocol |Security Manager | 163 +--------------------+-------------------+ 164 | Logical Link Control and Adaptation | 165 +--------------------+-------------------+ 166 | Host Controller Interface | 167 +--------------------+-------------------+ 168 | Link Layer | Direct Test Mode | 169 +--------------------+-------------------+ 170 | Physical Layer | 171 +--------------------+-------------------+ 172 Figure 1: BT-LE Protocol Stack 174 3.1. Support for IPv6 over BT-LE 176 Either a connection oriented channel SHOULD be added to the current 177 BT-LE specification, over which parts of 6LoWPAN, IPv6 and 178 application protocols can be run or a new fixed channel ID SHOULD be 179 reserved for IPv6 traffic. Figure 2 illustrates IPv6 over BT-LE 180 stack. 182 CoAP is a lightweight protocol specifically designed for resource 183 constrained RESTful environments. CoAP is similar to HTTP but more 184 compact and runs on UDP. CoAP supports simple Create, Read, Write 185 and Delete operations on resources (URIs). CoAP also provides 186 mapping to normal HTTP. CoAP overhead in requests is 5 bytes, in 187 responses 4 bytes. When considering the total IPv6 + UDP +CoAP 188 overhead in requests and responses it would be 10-11 Bytes with link 189 local addresses and 34-35 Bytes with global addresses. The rest is 190 URL + real payload. If HTTP/TCP was used instead of CoAP/UDP, IPv6 + 191 TCP headers alone would take 22 Bytes with link local addresses and 192 55 Bytes with global addresses assuming that optional timestamps in 193 TCP headers are not used. HTTP overhead, which can vary, will be 194 added on top of these. Taking into account the small size of 195 physical layer BT-LE PDUs (maximum 255 Bytes in some implementations 196 excluding headers), URL can not be too long considering that enough 197 space has to be left for the actual payload. URLs could be e.g. '/t' 198 instead of '/temperature', and payload can be binary instead of 199 ASCII. 201 +-------------------+ 202 | Applications | 203 +-------------------+ 204 | (CoAP/HTTP) | 205 +-------------------+ 206 | (UDP/TCP) | 207 +-------------------+ 208 | Compressed IPv6 | 209 +-------------------+ 210 | BT-LE L2CAP | 211 +-------------------+ 212 | BT-LE Link Layer | 213 +-------------------+ 214 | BT-LE Physical | 215 +-------------------+ 216 Figure 2: IPv6 over BT-LE Stack 218 4. Requirements 220 BT-LE technology sets strict requirements for low power consumption 221 and thus limits the allowed protocol overhead. 6LoWPAN standard 222 [RFC4944] provides useful generic functionality like header 223 compression, link-local IPv6 addresses, Neighbor Discovery and 224 stateless IP-address autoconfiguration for reducing the overhead in 225 802.15.4 networks. This functionality can be partly applied to 226 BT-LE. 228 5. Bluetooth Low Energy roles and network topology 230 BT-LE defines two Link Layer roles: the Master Role and the Slave 231 Role. A device in the Master Role, which is called master, can 232 manage multiple simultaneous connections with a number of devices in 233 the Slave Role, called slaves. A slave can only be connected to a 234 single master. Hence, a BT-LE network (i.e. a BT-LE piconet) follows 235 a star topology. 237 A master is assumed to be less constrained than a slave. Hence, 238 master and slave can correlate with 6LBR and host, respectively. 240 A significant difference between IEEE 802.15.4 and BT-LE is that the 241 former supports the mesh topology (and requires a routing protocol), 242 whereas BT-LE does not currently support the formation of multihop 243 networks. In consequence, the mesh header defined in [RFC4944] for 244 mesh under routing MUST NOT be used in BT-LE networks. On the other 245 hand, a BT-LE device MUST NOT play the role of a 6LR. 247 In BT-LE, communication only takes place between a master and a 248 slave. Hence, in a BT-LE network using IP, a radio hop is equivalent 249 to an IP link and vice versa. 251 6. BT-LE network connectivity scenarios 253 In many applications, the BT-LE network will be connected to the 254 Internet. In this case, the master/6LBR has at least one non-BT-LE 255 interface connected to the Internet. 257 h ____________ 258 \ / \ 259 h ---- 6LBR --- | Internet | 260 / \____________/ 261 h 262 h: host 263 <-- BT-LE --> 6LBR: 6LoWPAN Border Router 265 Figure 3: BT-LE network connected to the Internet 267 6to4 and 6RD are possibilities when the 6LBR has only IPv4 uplink 268 connectivity. The 6LBR would act as 6to4/6RD router and advertise 269 6to4/6RD prefix into the BT-LE network. The 6to4 prefix is 270 constructed by combining well-known IPv6 prefix with public IPv4 271 address. The 6RD prefix is constructed by combining network specific 272 IPv6 prefix with public or private IPv4 addresses. These 273 technologies require the 6LBR device to perform IPv6 into IPv4 274 encapsulation, and in particular in 6RD case also require tunnel 275 endpoint in the access network. 277 If the 6LBR has no IPv6 uplink Internet connectivity available via 278 any of the abovementioned means, the 6LBR may employ IPv6 to IPv4 279 protocol translation technology. This allows BT-LE nodes to connect 280 to Internet destinations as long as the destination has globally 281 reachable IPv4 address. The BT-LE network would be numbered with ULA 282 addresses, which IPv6 stacks on BT-LE nodes would consider as global 283 addresses. 285 In some scenarios, the BT-LE network may transiently or permanently 286 be an isolated network. 288 h h h: host 289 \ / 6LBR: 6LoWPAN Border Router 290 h --- 6LBR -- h 291 / \ 292 h h 294 Figure 4: Isolated BT-LE network 296 7. Addressing Model 298 The link model of BT-LE needs to be considered and what kind of 299 addressing is possible. 301 8. MTU Issues 303 Generally the sensors generate data that fits into one Link Layer 304 packet (23 bytes) that is transferred to the collector periodically. 305 IP data packets may be much larger and hence MTU size should be the 306 size of the IP data packet. Larger L2CAP packets can be transferred 307 with the Segmentation And Reassembly (SAR) feature of the Link Layer. 308 If an implementation cannot support the larger MTU size (due to cost) 309 then SAR MUST be supported at upper layers. 311 Existing SAR functionality defined in [RFC4944] MAY also be used, 312 taking into account BT-LE specific features such as different MTU in 313 the L2CAP layer. 315 9. LoWPAN Adaptation for BT-LE and frame format 317 Transmission of IPv6 Packets over IEEE 802.15.4 Networks [RFC4944] 318 defines an adaptation layer between IP and 802.15.4 radio networks. 319 In these networks link layer does not support SAR functionality and 320 thus IP packets must fit into the payload that is available in the 321 127 octect long physical frame after variable size frame overhead has 322 been added. In BT-LE networks this kind of adaptation is not 323 required if SAR is supported in the Link Layer. 325 10. IPv6 Address configuration 327 The Interface Identifier for a BT-LE interface MAY be formed from the 328 48-bit public device Bluetooth address as per the "IPv6 over 329 Ethernet" specification [RFC2464]. 331 An IPv6 prefix used for stateless autoconfiguration [RFC4862] of a 332 BT-LE interface MUST have a length of 64 bits. 334 SLAAC and other means to configure an address on a BT-LE device. 335 Neighbor Discovery Optimization for Low-power and Lossy Networks 336 [I-D.ietf-6lowpan-nd]. Well-known gateway or server addresses can be 337 hard-coded in the sensors. 339 11. IPv6 LLA in BLE 341 The IPv6 link-local address [RFC4291] for a BT-LE interface is formed 342 by appending the Interface Identifier, as defined above, to the 343 prefix FE80::/64. 345 10 bits 54 bits 64 bits 346 +----------+-----------------+----------------------+ 347 |1111111010| zeros | Interface Identifier | 348 +----------+-----------------+----------------------+ 350 Figure 5: IPv6 link-local address in BT-LE 352 12. Unicast and Multicast address mapping 354 Reuse the same format specified for 802.15.4? 356 13. Header compression 358 Compression Format for IPv6 Datagrams in Low Power and Lossy Networks 359 (6LoWPAN) [I-D.ietf-6lowpan-hc] is the basis of the IPv6 header 360 compression mechanism defined in this specification. Whereas 361 [I-D.ietf-6lowpan-hc] exploits intra-packet redundancies due to the 362 formation of Interface Identifiers from MAC addresses, BT-LE data 363 channel PDUs include neither source nor destination MAC addresses. 364 Instead, BT-LE Link Layer packets include the Access Address, a 32- 365 bit value that identifies a Link Layer connection between a master 366 and a slave. In consequence, the Interface Identifier compression 367 mechanisms used in this specification are different from those used 368 in [I-D.ietf-6lowpan-hc]. 370 In [RFC4944] different types of frame formats and related headers 371 have been defined to support fragmentation and mesh addressing. In 372 BT-LE context latest version of LoWPAN compressed IPv6 header SHOULD 373 be used by default. Support for fragmentation and mesh headers MAY 374 be added. However, since BT-LE operates on a star topology, mesh 375 headers SHOULD not be required. In BT-LE link with header 376 compression IPv6 header (originally 40 Bytes) can be compressed to 377 only 2 Bytes with link-local addresses and 26 Bytes with Global 378 addresses. UDP header (originally 8 Bytes) can be compressed to 4 379 Bytes. 381 This specification assumes that the following will be the common case 382 when using IPv6 on top of BT-LE networks: Version is 6; Traffic Class 383 and Flow Label are both zero; Payload Length can be inferred from 384 lower layers from either the 6LoWPAN Fragmentation header or the 385 BT-LE Link Layer header; Hop Limit will be set to a well-known value 386 by the source; IPv6 addresses assigned to BT-LE interfaces will be 387 formed using the link-local prefix or a small set of routable 388 prefixes assigned to the entire BT-LE network. 390 In a link-local communication, the IPv6 destination address can be 391 elided. In fact, the node that receives a data channel PDU through a 392 Link Layer connection can infer that the IPv6 destination address of 393 the packet is its own IPv6 address. If a node knows the IPv6 address 394 of the other endpoint of the Link Layer connection, the IPv6 source 395 address can also be elided. The mechanism by which a node learns the 396 IPv6 link-local address (or the Interface Identifier) of the other 397 endpoint of the connection is TBD. 399 When a BT-LE slave transmits an IPv6 packet to a remote destination 400 using global IPv6 addresses, the slave can elide the IPv6 source 401 address. This is possible if the following two conditions are met: 402 1) the master/6LBR can derive the prefix of the source IPv6 address 403 from a context shared with the slaves; and 2) the master/6LBR 404 maintains a table that relates the Access Address of each Link Layer 405 connection and the Interface Identifier of the corresponding slave. 406 The mechanism by which the master/6LBR maintains the above mentioned 407 table is TBD. The slave can also elide the prefix of the destination 408 IPv6 address if a context is defined for the IPv6 destination 409 address. 411 When a master/6LBR receives an IPv6 packet sent by a remote node 412 outside the BT-LE network, and the destination of the packet is a 413 slave, the master/6LBR can elide the Interface Identifier of the IPv6 414 destination address by exploiting the information contained in the 415 table mentioned above. The prefixes of the IPv6 destination and 416 source addresses can also be elided if a context is defined for them. 418 Some parts of the base HC encoding may need to be modified/redefined 419 in order to enable the new functionality described herein. TBD in 420 future versions. 422 In a link-local communication, the IPv6 header can be compressed down 423 to 2 bytes in the best case. 425 14. IANA Considerations 427 This document does not have any IANA requests at this time. This may 428 change with further development of the specification. 430 15. Security Considerations 432 The transmission of IPv6 over bluetooth low energy links has similar 433 requirements and concerns for security as ZigBee. Security at the IP 434 layer needs to be reviewed as part of the development of the IPv6 435 over Bluetooth Low Energy specification. 437 BT-LE Link Layer supports encryption and authentication by using the 438 CCM mechanism and a 128-bit AES block cipher. Upper layer security 439 mechanisms may exploit this functionality when it is available. 440 (Note: CCM does not consume bytes from the maximum per-packet L2CAP 441 data size, since the link layer data unit has a specific field for 442 them when they are used.) 444 Key management in BT-LE is provided by the Security Manager Protocol 445 (SMP). 447 16. Additional contributors 449 Kanji Kerai and Jari Mutikainen from Nokia have contributed 450 significantly to this document. 452 17. Normative References 454 [I-D.ietf-6lowpan-hc] 455 Hui, J. and P. Thubert, "Compression Format for IPv6 456 Datagrams in Low Power and Lossy Networks (6LoWPAN)", 457 draft-ietf-6lowpan-hc-15 (work in progress), 458 February 2011. 460 [I-D.ietf-6lowpan-nd] 461 Shelby, Z., Chakrabarti, S., and E. Nordmark, "Neighbor 462 Discovery Optimization for Low-power and Lossy Networks", 463 draft-ietf-6lowpan-nd-15 (work in progress), 464 December 2010. 466 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 467 Requirement Levels", BCP 14, RFC 2119, March 1997. 469 [RFC2464] Crawford, M., "Transmission of IPv6 Packets over Ethernet 470 Networks", RFC 2464, December 1998. 472 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 473 Architecture", RFC 4291, February 2006. 475 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 476 Address Autoconfiguration", RFC 4862, September 2007. 478 [RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler, 479 "Transmission of IPv6 Packets over IEEE 802.15.4 480 Networks", RFC 4944, September 2007. 482 [RFC4994] Zeng, S., Volz, B., Kinnear, K., and J. Brzozowski, 483 "DHCPv6 Relay Agent Echo Request Option", RFC 4994, 484 September 2007. 486 Appendix A. Bluetooth Low Energy basics 488 This section will provide background material on the basics of 489 bluetooth low energy. 491 Authors' Addresses 493 Johanna Nieminen (editor) 494 Nokia 495 Itaemerenkatu 11-13 496 FI-00180 Helsinki 497 Finland 499 Email: johanna.1.nieminen@nokia.com 501 Basavaraj Patil 502 Nokia 503 6021 Connection drive 504 Irving, TX 75039 505 USA 507 Email: basavaraj.patil@nokia.com 509 Teemu Savolainen 510 Nokia 511 Hermiankatu 12 D 512 FI-33720 Tampere 513 Finland 515 Email: teemu.savolainen@nokia.com 517 Markus Isomaki 518 Nokia 519 Keilalahdentie 2-4 520 FI-02150 Espoo 521 Finland 523 Email: markus.isomaki@nokia.com 524 Zach Shelby 525 Sensinode 526 Hallituskatu 13-17D 527 FI-90100 Oulu 528 Finland 530 Email: zach.shelby@sensinode.com 532 Carles Gomez 533 Universitat Politecnica de Catalunya/i2CAT 534 C/Esteve Terradas, 7 535 Castelldefels 08860 536 Spain 538 Email: carlesgo@entel.upc.edu