idnits 2.17.1 draft-ietf-6lowpan-btle-11.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 12, 2012) is 4212 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) -- 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 (~~), 1 warning (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 6LoWPAN Working Group J. Nieminen, Ed. 3 Internet-Draft T. Savolainen, Ed. 4 Intended status: Standards Track M. Isomaki 5 Expires: April 15, 2013 Nokia 6 B. Patil 8 Z. Shelby 9 Sensinode 10 C. Gomez 11 Universitat Politecnica de 12 Catalunya/i2CAT 13 October 12, 2012 15 Transmission of IPv6 Packets over BLUETOOTH Low Energy 16 draft-ietf-6lowpan-btle-11 18 Abstract 20 BLUETOOTH Low Energy is a low power air interface technology defined 21 by the BLUETOOTH Special Interest Group (BT-SIG). The standard 22 BLUETOOTH radio has been widely implemented and available in mobile 23 phones, notebook computers, audio headsets and many other devices. 24 The low power version of BLUETOOTH is a new specification that 25 enables the use of this air interface with devices such as sensors, 26 smart meters, appliances, etc. The low power variant of BLUETOOTH is 27 currently specified in the revision 4.0 of the BLUETOOTH 28 specifications (BLUETOOTH 4.0). This document describes how IPv6 is 29 transported over BLUETOOTH Low Energy using 6LoWPAN 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 April 15, 2013. 48 Copyright Notice 49 Copyright (c) 2012 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. Terminology and Requirements Language . . . . . . . . . . 3 66 2. BLUETOOTH Low Energy . . . . . . . . . . . . . . . . . . . . . 3 67 2.1. BLUETOOTH Low Energy stack . . . . . . . . . . . . . . . . 4 68 2.2. Link layer roles and topology . . . . . . . . . . . . . . 4 69 2.3. BT-LE device addressing . . . . . . . . . . . . . . . . . 5 70 2.4. BT-LE packets sizes and MTU . . . . . . . . . . . . . . . 5 71 3. Specification of IPv6 over BLUETOOTH Low Energy . . . . . . . 6 72 3.1. Protocol stack . . . . . . . . . . . . . . . . . . . . . . 6 73 3.2. Link model . . . . . . . . . . . . . . . . . . . . . . . . 7 74 3.2.1. Stateless address autoconfiguration . . . . . . . . . 8 75 3.2.2. Neighbor discovery . . . . . . . . . . . . . . . . . . 9 76 3.2.3. Header compression . . . . . . . . . . . . . . . . . . 9 77 3.2.4. Unicast and Multicast address mapping . . . . . . . . 10 78 3.3. Internet connectivity scenarios . . . . . . . . . . . . . 11 79 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 80 5. Security Considerations . . . . . . . . . . . . . . . . . . . 12 81 6. Additional contributors . . . . . . . . . . . . . . . . . . . 12 82 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12 83 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 84 8.1. Normative References . . . . . . . . . . . . . . . . . . . 13 85 8.2. Informative References . . . . . . . . . . . . . . . . . . 13 86 Appendix A. BLUETOOTH Low Energy fragmentation and L2CAP Modes . 14 87 Appendix B. BLUETOOTH Low Energy L2CAP Channel ID Usage for 88 6LoWPAN/IPv6 . . . . . . . . . . . . . . . . . . . . 14 89 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15 91 1. Introduction 93 BLUETOOTH Low Energy (BT-LE) is a radio technology targeted for 94 devices that operate with coin cell batteries or minimalistic power 95 sources, which means that low power consumption is essential. BT-LE 96 is an especially attractive technology for Internet of Things 97 applications, such as health monitors, environmental sensing, 98 proximity applications and many others. 100 Considering the potential for the exponential growth in the number of 101 sensors and Internet connected devices and things, IPv6 is an ideal 102 protocol due to the large address space it provides. In addition, 103 IPv6 provides tools for stateless address autoconfiguration, which is 104 particularly suitable for sensor network applications and nodes which 105 have very limited processing power or lack a full-fledged operating 106 system. 108 RFC 4944 [RFC4944] specifies the transmission of IPv6 over IEEE 109 802.15.4. The BT-LE link in many respects has similar 110 characteristics to that of IEEE 802.15.4. Many of the mechanisms 111 defined in the RFC 4944 can be applied to the transmission of IPv6 on 112 BT-LE links. This document specifies the details of IPv6 113 transmission over BT-LE links. 115 1.1. Terminology and Requirements Language 117 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 118 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 119 document are to be interpreted as described in RFC 2119 [RFC2119]. 121 The terms 6LN, 6LR and 6LBR are defined as in [I-D.ietf-6lowpan-nd], 122 with an addition that BT-LE master and BT-LE slave can both be either 123 6LN or 6LBR. 125 2. BLUETOOTH Low Energy 127 BT-LE is designed for transferring small amounts of data infrequently 128 at modest data rates at a very low cost per bit. BLUETOOTH Special 129 Interest Group has introduced two trademarks, BLUETOOTH Smart for 130 single-mode devices (a device that only supports BT-LE) and BLUETOOTH 131 Smart Ready for dual-mode devices. In the rest of the draft, the 132 term BT-LE refers to both types of devices. 134 BT-LE is an integral part of the BT 4.0 specification [BTCorev4.0]. 135 Devices such as mobile phones, notebooks, tablets and other handheld 136 computing devices which include BT 4.0 chipsets also have the low- 137 energy functionality of BLUETOOTH. BT-LE is also included in many 138 different types of accessories that collaborate with mobile devices 139 such as phones, tablets and notebook computers. An example of a use 140 case for a BT-LE accessory is a heart rate monitor that sends data 141 via the mobile phone to a server on the Internet. 143 2.1. BLUETOOTH Low Energy stack 145 The lower layer of the BT-LE stack consists of the Physical (PHY) and 146 the Link Layer (LL). The Physical Layer transmits and receives the 147 actual packets. The Link Layer is responsible for providing medium 148 access, connection establishment, error control and flow control. 149 The upper layer consists of the Logical Link Control and Adaptation 150 Protocol (L2CAP), Generic Attribute protocol (GATT) and Generic 151 Access Profile (GAP) as shown in Figure 1. GATT and BT-LE profiles 152 together enable the creation of applications in a standardized way 153 without using IP. L2CAP provides multiplexing capability by 154 multiplexing the data channels from the above layers. L2CAP also 155 provides fragmentation and reassembly for large data packets. 157 +----------------------------------------+------------------+ 158 | Applications | 159 +----------------------------------------+------------------+ 160 | Generic Attribute Profile | Generic Access | 161 +----------------------------------------+ Profile | 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 +--------------------+-------------------+------------------+ 173 Figure 1: BT-LE Protocol Stack 175 2.2. Link layer roles and topology 177 BT-LE defines two Link Layer roles: the BT-LE master role and the 178 BT-LE slave role. A device in the master role, which is called 179 master from now on, can manage multiple simultaneous connections with 180 a number of devices in the slave role, called slaves from now on. A 181 slave can only be connected to a single master. Hence, a BT-LE 182 network (i.e. a BT-LE piconet) follows a star topology shown in the 183 Figure 2. This specification primarily addresses the situation where 184 the slave is a 6LN but not a 6LBR at the IPv6 level. 186 [BT-LE slave]-----\ /-----[BT-LE slave] 187 \ / 188 [BT-LE slave]-----+[BT-LE Master]+-----[BT-LE slave] 189 / \ 190 [BT-LE slave]-----/ \-----[BT-LE slave] 192 Figure 2: BT-LE Star Topology 194 A master is assumed to be less constrained than a slave. Hence, in 195 the primary scenario master and slave will act as 6LoWPAN Border 196 Router (6LBR) and a 6LoWPAN Node (6LN), respectively. 198 In BT-LE, communication only takes place between a master and a 199 slave. Hence, in a BT-LE network using IPv6, a radio hop is 200 equivalent to an IPv6 link and vice versa. 202 2.3. BT-LE device addressing 204 Every BT-LE device is identified by a 48-bit device address. The 205 BLUETOOTH specification describes the device address of a BTLE device 206 as:"Devices are identified using a device address. Device addresses 207 may be either a public device address or a random device address." 208 [BTCorev4.0]. The public device addresses are based on the IEEE 802- 209 2001 standard [IEEE802-2001]. The random device addresses are 210 generated as defined in the BLUETOOTH specification. The device 211 addresses are always unique within a BT-LE piconet, but the random 212 addresses are not guaranteed to be globally unique. 214 2.4. BT-LE packets sizes and MTU 216 Maximum size of the payload in the BT-LE data channel PDU is 27 217 bytes. Depending on the L2CAP mode in use, the amount of data 218 available for transporting bytes in the single BT-LE data channel PDU 219 ranges between 19 and 27 octets. For power efficient communication 220 between two BT-LE nodes, data and its header should fit in a single 221 BT-LE data channel PDU. However, IPv6 requires support for an MTU of 222 1280 bytes. An inherent function of the BT-LE L2CAP layer, called 223 Fragmentation and Recombination (FAR), can assist in transferring 224 IPv6 packets that do not fit in a single BT-LE data channel PDU. 226 The maximum IPv6 datagram size that can be transported by L2CAP 227 depends on the L2CAP mode. The Basic L2CAP Mode allows a maximum 228 payload size (i.e. IPv6 datagram size) of 65535 bytes per L2CAP PDU. 230 The rest of the L2CAP modes allow a maximum payload size that ranges 231 between 65527 and 65533 bytes per L2CAP PDU. Appendix A describes 232 FAR operation and five L2CAP Modes. 234 3. Specification of IPv6 over BLUETOOTH Low Energy 236 BT-LE technology sets strict requirements for low power consumption 237 and thus limits the allowed protocol overhead. 6LoWPAN standards 238 [RFC4944], [I-D.ietf-6lowpan-nd] and [RFC6282] provide useful generic 239 functionality like header compression (see Section 3.2.3), link-local 240 IPv6 addresses, Neighbor Discovery (see Section 3.2.2) and stateless 241 IPv6 address autoconfiguration (see Section 3.2.1) for reducing the 242 overhead in 802.15.4 networks. This functionality can be partly 243 applied to BT-LE. 245 A significant difference between IEEE 802.15.4 and BT-LE is that the 246 former supports both star and mesh topology (and requires a routing 247 protocol), whereas BT-LE does not currently support the formation of 248 multihop networks at the link layer. In consequence, the mesh header 249 defined in [RFC4944] for mesh under routing MUST NOT be used in BT-LE 250 networks. In addition, a BT-LE node MUST NOT play the role of a 251 6LoWPAN Router (6LR). 253 3.1. Protocol stack 255 In order to enable transmission of IPv6 packets over BT-LE, a new 256 fixed L2CAP Channel Identifier (Channel ID) is to be reserved for 257 IPv6 traffic by the BT-SIG. Until the Channel ID is reserved, 258 prototype implementations can be implemented as is described in the 259 Appendix B. 261 Figure 3 illustrates IPv6 over BT-LE stack. UDP and TCP are provided 262 as examples of transport protocols, but the stack can be used by any 263 other upper layer protocol capable of running atop of IPv6. 265 +----------------------------+ 266 | UDP/TCP/other | 267 +----------------------------+ 268 | IPv6 | 269 +----------------------------+ 270 | 6LoWPAN adapted to BT-LE | 271 +----------------------------+ 272 | BT-LE L2CAP | 273 +----------------------------+ 274 | BT-LE Link Layer | 275 +----------------------------+ 276 | BT-LE Physical | 277 +----------------------------+ 279 Figure 3: IPv6 over BT-LE Stack 281 3.2. Link model 283 The concept of IPv6 link (layer 3) and the physical link (combination 284 of PHY and MAC) needs to be clear and the relationship has to be well 285 understood in order to specify the addressing scheme for transmitting 286 IPv6 packets over the BT-LE link. RFC 4861 [RFC4861] defines a link 287 as "a communication facility or medium over which nodes can 288 communicate at the link layer, i.e., the layer immediately below 289 IPv6." 291 In the case of BT-LE, L2CAP is an adaptation layer that supports the 292 transmission of IPv6 packets. L2CAP also provides multiplexing 293 capability in addition to FAR functionality. This specification 294 requires that FAR functionality MUST be provided in the L2CAP layer. 295 The L2CAP channel characteristics for the transmission of IPv6 296 packets on top of BT-LE are the following: 298 MTU: Equal to or greater than 1280 bytes 300 Flush Timeout: 0xFFFF (Infinite) 302 QoS: Best Effort 304 Mode: Basic Mode 306 Since FAR in BT-LE is a function of the L2CAP layer, fragmentation 307 functionality as defined in RFC 4944 [RFC4944] MUST NOT be used in 308 BT-LE networks. This specification also assumes the IPv6 header 309 compression format specified in RFC 6282 [RFC6282]. It is also 310 assumed that the IPv6 payload length can be inferred from the L2CAP 311 header length and the IID value inferred, with help of Neighbor 312 Cache, from the link-layer address. 314 The BT-LE link between two communicating nodes can be considered to 315 be a point-to-point or point-to-multipoint link. When one of the 316 communicating nodes is in the role of a master, then the link can be 317 viewed as a point-to-multipoint link from the master point of view. 318 However, due to BT-LE star topology, each branch of the star is 319 considered to be an individual link and thus the slaves cannot 320 directly hear each other and also cannot talk to each other with 321 link-local addresses. The master ensures address collisions do not 322 occur (see Section 3.2.2). 324 After the slave and master have connected at the BT-LE level, the 325 link can be considered up and IPv6 address configuration and 326 transmission can begin. 328 3.2.1. Stateless address autoconfiguration 330 A BT-LE 6LN performs stateless address autoconfiguration as per RFC 331 4862 [RFC4862]. A 64-bit Interface identifier (IID) for a BT-LE 332 interface MAY be formed by utilizing the 48-bit BLUETOOTH device 333 address (see Section 2.3) as defined in RFC 2464 "IPv6 over Ethernet" 334 specification [RFC2464]. Alternatively, a randomly generated IID 335 (see Section 3.2.2), MAY be used instead. In the case of randomly 336 generated IID or randomly generated BLUETOOTH device address, the 337 "Universal/Local" bit MUST be set to 0 [RFC4291]. Only if the 338 BLUETOOTH device address is known to be a public address the 339 "Universal/Local" bit can be set to 1. 341 As defined in RFC 4291 [RFC4291], the IPv6 link-local address for a 342 BT-LE node is formed by appending the IID, to the prefix FE80::/64, 343 as depicted in Figure 4. 345 10 bits 54 bits 64 bits 346 +----------+-----------------+----------------------+ 347 |1111111010| zeros | Interface Identifier | 348 +----------+-----------------+----------------------+ 350 Figure 4: IPv6 link-local address in BT-LE 352 The tool for a 6LBR to obtain an IPv6 prefix for numbering the BT-LE 353 network is out of scope of this document, but can be, for example, 354 accomplished via DHCPv6 Prefix Delegation [RFC3633] or by using 355 Unique Local IPv6 Unicast Addresses (ULA) [RFC4193]. Due to the link 356 model of the BT-LE (see Section 2.2) the 6LBR MUST set the "on-link" 357 flag (L) to zero in the Prefix Information Option [RFC4861]. This 358 will cause 6LNs to always send packets to the 6LBR, including the 359 case when the destination is another 6LN using the same prefix. 361 3.2.2. Neighbor discovery 363 'Neighbor Discovery Optimization for Low Power and Lossy Networks' 364 [I-D.ietf-6lowpan-nd] describes the neighbor discovery approach as 365 adapted for use in several 6LoWPAN topologies, including the mesh 366 topology. BT-LE does not support mesh networks and hence only those 367 aspects that apply to a star topology are considered. 369 The following aspects of the Neighbor Discovery optimizations 370 [I-D.ietf-6lowpan-nd] are applicable to BT-LE 6LNs: 372 1. A BT-LE 6LN MUST register its address with the 6LBR by sending a 373 Neighbor Solicitation (NS) message with the ARO option and process 374 the Neighbor Advertisement (NA) accordingly. The NS with the ARO 375 option SHOULD be sent irrespective of whether the IID is derived from 376 the unique 48 bit BT-LE device address or the IID is a random value 377 that is generated as per the privacy extensions for stateless address 378 autoconfiguration [RFC4941]. Although RFC 4941 [RFC4941] permits the 379 use of deprecated addresses for old connections, in this 380 specification we mandate that one interface MUST NOT use more than 381 one IID at any one time. 383 2. For sending Router Solicitations and processing Router 384 Advertisements the BT-LE 6LNs MUST, respectively, follow Sections 5.3 385 and 5.4 of the [I-D.ietf-6lowpan-nd]. 387 3.2.3. Header compression 389 Header compression as defined in RFC 6282 [RFC6282], which specifies 390 the compression format for IPv6 datagrams on top of IEEE 802.15.4, is 391 REQUIRED in this document as the basis for IPv6 header compression on 392 top of BT-LE. All headers MUST be compressed according to RFC 6282 393 [RFC6282] encoding formats. The BT-LE's star topology structure can 394 be exploited in order to provide a mechanism for IID compression. 395 The following text describes the principles of IPv6 address 396 compression on top of BT-LE. 398 In a link-local communication, both the IPv6 source and destination 399 addresses MUST be elided [RFC6282], since the node knows that the 400 packet is destined for it even if the packet does not have 401 destination IPv6 address. On the other hand, a node SHALL learn the 402 IID of the other endpoint of each L2CAP connection it participates 403 in. By exploiting this information, a node that receives a data 404 channel PDU containing an IPv6 packet (or a part of it) can infer the 405 corresponding IPv6 source address. A node MUST maintain a Neighbor 406 Cache, in which the entries include both the IID of the neighbor and 407 the Device Address that identifies the neighbor. For the type of 408 communication considered in this paragraph, the following settings 409 MUST be used in the IPv6 compressed header: CID=0, SAC=0, SAM=11, 410 DAC=0, DAM=11. 412 When a 6LN transmits an IPv6 packet to a remote destination using 413 global Unicast IPv6 addresses, if a context is defined for the prefix 414 of the 6LNs global IPv6 address, the 6LN MUST indicate this context 415 in the corresponding source fields of the compressed IPv6 header as 416 per Section 3.1 of RFC 6282 [RFC6282], and MUST elide the IPv6 source 417 address. For this, the 6LN MUST use the following settings in the 418 IPv6 compressed header: CID=1, SAC=1, SAM=11. In this case, the 6LBR 419 can infer the elided IPv6 source address since 1) the 6LBR has 420 previously assigned the prefix to the 6LNs; and 2) the 6LBR maintains 421 a Neighbor Cache that relates the Device Address and the IID of the 422 corresponding slave. If a context is defined for the IPv6 423 destination address, the 6LN MUST also indicate this context in the 424 corresponding destination fields of the compressed IPv6 header, and 425 MUST elide the prefix of the destination IPv6 address. For this, the 426 6LN MUST set the DAM field of the compressed IPv6 header as DAM=01 427 (if the context covers a 64-bit prefix) or as DAM=11 (if the context 428 covers a full, 128-bit address). CID and DAC MUST be set to CID=1 429 and DAC=1. Note that when a context is defined for the IPv6 430 destination address, the 6LBR can infer the elided destination prefix 431 by using the context. 433 When a 6LBR receives an IPv6 packet sent by a remote node outside the 434 BT-LE network, and the destination of the packet is a 6LN, if a 435 context is defined for the prefix of the 6LN's global IPv6 address, 436 the 6LBR MUST indicate this context in the corresponding destination 437 fields of the compressed IPv6 header, and MUST elide the IPv6 438 destination address of the packet before forwarding it to the 6LN. 439 For this, the 6LBR MUST set the DAM field of the IPv6 compressed 440 header as DAM=11. CID and DAC MUST be set to CID=1 and DAC=1. If a 441 context is defined for the prefix of the IPv6 source address, the 442 6LBR MUST indicate this context in the source fields of the 443 compressed IPv6 header, and MUST elide that prefix as well. For 444 this, the 6LBR MUST set the SAM field of the IPv6 compressed header 445 as SAM=01 (if the context covers a 64-bit prefix) or SAM=11 (if the 446 context covers a full, 128-bit address). CID and SAC MUST be set to 447 CID=1 and SAC=1. 449 3.2.4. Unicast and Multicast address mapping 451 The BT-LE link layer does not support multicast. Hence traffic is 452 always unicast between two BT-LE nodes. Even in the case where a 453 master is attached to multiple slaves, the master cannot do a 454 multicast to all the connected slaves. If the master needs to send a 455 multicast packet to all its slaves, it has to replicate the packet 456 and unicast it on each link. However, this may not be energy- 457 efficient and particular care must be taken if the master is battery- 458 powered. In the opposite direction, a slave can only transmit data 459 to a single destination (i.e. the master). Hence, when a slave needs 460 to transmit an IPv6 multicast packet, the slave will unicast the 461 corresponding BT-LE packet to the master. As described in the 462 Section 3.2 the master will not forward link-local multicast messages 463 to other slaves connected to the master. 465 3.3. Internet connectivity scenarios 467 In a typical scenario, the BT-LE network is connected to the Internet 468 as shown in the Figure 5. 470 A degenerate scenario can be imagined where a slave is acting as 6LBR 471 and providing Internet connectivity for the master. How the master 472 could then further provide Internet connectivity to other slaves, 473 possibly connected to the master, is out of the scope of this 474 document. 476 6LN 477 \ ____________ 478 \ / \ 479 6LN ---- 6LBR --- | Internet | 480 / \____________/ 481 / 482 6LN 484 <-- BT-LE --> 486 Figure 5: BT-LE network connected to the Internet 488 In some scenarios, the BT-LE network may transiently or permanently 489 be an isolated network as shown in the Figure 6. 491 6LN 6LN 492 \ / 493 \ / 494 6LN --- 6LBR --- 6LN 495 / \ 496 / \ 497 6LN 6LN 499 <------ BT-LE -----> 500 Figure 6: Isolated BT-LE network 502 In the isolated network scenario communications between 6LN and 6LBR 503 can use IPv6 link-local methodology, but for communications between 504 different slaves, the master has to act as 6LBR, number the network 505 with ULA prefix [RFC4193], and route packets between slaves. 507 4. IANA Considerations 509 There are no IANA considerations related to this document. 511 5. Security Considerations 513 The transmission of IPv6 over BT-LE links has similar requirements 514 and concerns for security as for IEEE 802.15.4. IPv6 over BT-LE 515 SHOULD be protected by using BT-LE Link Layer security. 517 BT-LE Link Layer supports encryption and authentication by using the 518 Counter with CBC-MAC (CCM) mechanism [RFC3610] and a 128-bit AES 519 block cipher. Upper layer security mechanisms may exploit this 520 functionality when it is available. (Note: CCM does not consume 521 bytes from the maximum per-packet L2CAP data size, since the link 522 layer data unit has a specific field for them when they are used.) 524 Key management in BT-LE is provided by the Security Manager Protocol 525 (SMP), as defined in [BTCorev4.0]. 527 6. Additional contributors 529 Kanji Kerai, Jari Mutikainen, David Canfeng-Chen and Minjun Xi from 530 Nokia have contributed significantly to this document. 532 7. Acknowledgements 534 The BLUETOOTH, BLUETOOTH Smart and BLUETOOTH Smart Ready marks are 535 registred trademarks owned by BLUETOOTH SIG, Inc. 537 Samita Chakrabarti, Erik Nordmark, and Marcel De Kogel have provided 538 valuable feedback for this draft. 540 8. References 541 8.1. Normative References 543 [BTCorev4.0] 544 BLUETOOTH Special Interest Group, "BLUETOOTH Specification 545 Version 4.0", June 2010. 547 [I-D.ietf-6lowpan-nd] 548 Shelby, Z., Chakrabarti, S., and E. Nordmark, "Neighbor 549 Discovery Optimization for Low Power and Lossy Networks 550 (6LoWPAN)", draft-ietf-6lowpan-nd-21 (work in progress), 551 August 2012. 553 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 554 Requirement Levels", BCP 14, RFC 2119, March 1997. 556 [RFC2464] Crawford, M., "Transmission of IPv6 Packets over Ethernet 557 Networks", RFC 2464, December 1998. 559 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 560 Architecture", RFC 4291, February 2006. 562 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 563 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 564 September 2007. 566 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 567 Address Autoconfiguration", RFC 4862, September 2007. 569 [RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler, 570 "Transmission of IPv6 Packets over IEEE 802.15.4 571 Networks", RFC 4944, September 2007. 573 [RFC6282] Hui, J. and P. Thubert, "Compression Format for IPv6 574 Datagrams over IEEE 802.15.4-Based Networks", RFC 6282, 575 September 2011. 577 8.2. Informative References 579 [IEEE802-2001] 580 Institute of Electrical and Electronics Engineers (IEEE), 581 "IEEE 802-2001 Standard for Local and Metropolitan Area 582 Networks: Overview and Architecture", 2002. 584 [RFC3610] Whiting, D., Housley, R., and N. Ferguson, "Counter with 585 CBC-MAC (CCM)", RFC 3610, September 2003. 587 [RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic 588 Host Configuration Protocol (DHCP) version 6", RFC 3633, 589 December 2003. 591 [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast 592 Addresses", RFC 4193, October 2005. 594 [RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy 595 Extensions for Stateless Address Autoconfiguration in 596 IPv6", RFC 4941, September 2007. 598 Appendix A. BLUETOOTH Low Energy fragmentation and L2CAP Modes 600 This section provides an overview of Fragmentation and Recombination 601 (FAR) method and L2CAP modes in BT-LE. FAR is an L2CAP mechanism, in 602 which an L2CAP entity can take the (large) upper layer PDU, prepend 603 the L2CAP header (4 bytes in the Basic L2CAP mode) and break the 604 resulting L2CAP PDU into fragments which can then be directly 605 encapsulated into Data channel PDUs. There are bits in the Data 606 channel PDUs which identify whether the payload is a complete L2CAP 607 PDU or the first of a set of fragments, or one of the rest of the 608 fragments. 610 There are five L2CAP modes defined in the BT 4.0 spec. These modes 611 are: Retransmission Mode (a Go-Back-N mechanism is used), Enhanced 612 Retransmission Mode (includes selective NAK among others), Flow 613 Control Mode (PDUs are numbered, but there are no retransmissions), 614 Streaming Mode (PDUs are numbered, but there are no ACKs of any kind) 615 and Basic L2CAP Mode. 617 Appendix B. BLUETOOTH Low Energy L2CAP Channel ID Usage for 6LoWPAN/ 618 IPv6 620 The BT-LE Logical Link Control and Adaptation Protocol (L2CAP) uses 621 Channel Identifiers (IDs) to distinguish the upper layer protocol 622 carried on top of it. Two devices exchanging IPv6/6LoWPAN packets 623 need to use a common Channel ID to be able to send and receive the 624 packets correctly over L2CAP. It is also important that they avoid 625 using Channel ID's that conflict with other L2CAP usages. For the 626 initial use of IPv6/6LoWPAN over BT-LE L2CAP, implementers are 627 recommended to use Channel ID 0x3E from the BLUETOOTH Special 628 Interest Group reserved space (BLUETOOTH 4.0 Logical Link Control and 629 Adaptation Protocol Specification -part, table 2.1 [BTCorev4.0]). As 630 the IPv6/6LoWPAN use becomes more widely adopted, the BT SIG may 631 allocate 0x3E or some other Channel ID exclusively for IPv6/6LoWPAN. 632 Any such BT SIG allocation will deprecate the recommendation given in 633 this Appendix, and a new RFC will be published at the time of 634 allocation that will update this RFC and specify the allocated value. 636 The initial implementers are thus recommended to keep their Channel 637 ID usage capability flexible to potential future changes. 639 Authors' Addresses 641 Johanna Nieminen (editor) 642 Nokia 643 Itaemerenkatu 11-13 644 FI-00180 Helsinki 645 Finland 647 Email: johannamaria.nieminen@gmail.com 649 Teemu Savolainen (editor) 650 Nokia 651 Hermiankatu 12 D 652 FI-33720 Tampere 653 Finland 655 Email: teemu.savolainen@nokia.com 657 Markus Isomaki 658 Nokia 659 Keilalahdentie 2-4 660 FI-02150 Espoo 661 Finland 663 Email: markus.isomaki@nokia.com 665 Basavaraj Patil 666 6021 Connection drive 667 Irving, TX 75039 668 USA 670 Email: bpatil@ovi.com 671 Zach Shelby 672 Sensinode 673 Hallituskatu 13-17D 674 FI-90100 Oulu 675 Finland 677 Email: zach.shelby@sensinode.com 679 Carles Gomez 680 Universitat Politecnica de Catalunya/i2CAT 681 C/Esteve Terradas, 7 682 Castelldefels 08860 683 Spain 685 Email: carlesgo@entel.upc.edu