idnits 2.17.1 draft-ietf-6lowpan-btle-12.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 (February 12, 2013) is 4090 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: August 16, 2013 Nokia 6 B. Patil 8 Z. Shelby 9 Sensinode 10 C. Gomez 11 Universitat Politecnica de 12 Catalunya/i2CAT 13 February 12, 2013 15 Transmission of IPv6 Packets over BLUETOOTH Low Energy 16 draft-ietf-6lowpan-btle-12 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 August 16, 2013. 48 Copyright Notice 49 Copyright (c) 2013 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 [RFC6775], with an 122 addition that BT-LE master and BT-LE slave can both be either 6LN or 123 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], [RFC6775], and [RFC6282] provide useful functionality for 239 reducing overhead which can be applied to BT-LE. This functionality 240 comprises of link-local IPv6 addresses and stateless IPv6 address 241 autoconfiguration (see Section 3.2.1), Neighbor Discovery (see 242 Section 3.2.2) and header compression (see Section 3.2.3). 244 A significant difference between IEEE 802.15.4 and BT-LE is that the 245 former supports both star and mesh topology (and requires a routing 246 protocol), whereas BT-LE does not currently support the formation of 247 multihop networks at the link layer. In consequence, the mesh header 248 defined in [RFC4944] for mesh under routing MUST NOT be used in BT-LE 249 networks. In addition, a BT-LE node MUST NOT play the role of a 250 6LoWPAN Router (6LR). 252 3.1. Protocol stack 254 In order to enable transmission of IPv6 packets over BT-LE, a new 255 fixed L2CAP Channel Identifier (Channel ID) is to be reserved for 256 IPv6 traffic by the BT-SIG. Until the Channel ID is reserved, 257 prototype implementations can be implemented as is described in the 258 Appendix B. 260 Figure 3 illustrates IPv6 over BT-LE stack. UDP and TCP are provided 261 as examples of transport protocols, but the stack can be used by any 262 other upper layer protocol capable of running atop of IPv6. 264 +----------------------------+ 265 | UDP/TCP/other | 266 +----------------------------+ 267 | IPv6 | 268 +----------------------------+ 269 | 6LoWPAN adapted to 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 IPv6 link (layer 3) and the physical link (combination 283 of PHY and MAC) needs to be clear and the relationship has to be well 284 understood in order to specify the addressing scheme for transmitting 285 IPv6 packets over the BT-LE link. RFC 4861 [RFC4861] defines a link 286 as "a communication facility or medium over which nodes can 287 communicate at the link layer, i.e., the layer immediately below 288 IPv6." 290 In the case of BT-LE, L2CAP is an adaptation layer that supports the 291 transmission of IPv6 packets. L2CAP also provides multiplexing 292 capability in addition to FAR functionality. This specification 293 requires that FAR functionality MUST be provided in the L2CAP layer. 294 The L2CAP channel characteristics for the transmission of IPv6 295 packets on top of BT-LE are the following: 297 MTU: Equal to or greater than 1280 bytes 299 Flush Timeout: 0xFFFF (Infinite) 301 QoS: Best Effort 303 Mode: Basic Mode 305 Since FAR in BT-LE is a function of the L2CAP layer, fragmentation 306 functionality as defined in RFC 4944 [RFC4944] MUST NOT be used in 307 BT-LE networks. This specification also assumes the IPv6 header 308 compression format specified in RFC 6282 [RFC6282]. It is also 309 assumed that the IPv6 payload length can be inferred from the L2CAP 310 header length and the IID value inferred, with help of Neighbor 311 Cache, from the link-layer address. 313 The BT-LE link between two communicating nodes can be considered to 314 be a point-to-point or point-to-multipoint link. When one of the 315 communicating nodes is in the role of a master, then the link can be 316 viewed as a point-to-multipoint link from the master point of view. 317 However, due to BT-LE star topology, each branch of the star is 318 considered to be an individual link and thus the slaves cannot 319 directly hear each other and also cannot talk to each other with 320 link-local addresses. The master ensures address collisions do not 321 occur (see Section 3.2.2). 323 After the slave and master have connected at the BT-LE level, the 324 link can be considered up and IPv6 address configuration and 325 transmission can begin. 327 3.2.1. Stateless address autoconfiguration 329 A BT-LE 6LN performs stateless address autoconfiguration as per RFC 330 4862 [RFC4862]. A 64-bit Interface identifier (IID) for a BT-LE 331 interface MAY be formed by utilizing the 48-bit BLUETOOTH device 332 address (see Section 2.3) as defined in RFC 2464 "IPv6 over Ethernet" 333 specification [RFC2464]. Alternatively, a randomly generated IID 334 (see Section 3.2.2), MAY be used instead. In the case of randomly 335 generated IID or randomly generated BLUETOOTH device address, the 336 "Universal/Local" bit MUST be set to 0 [RFC4291]. Only if the 337 BLUETOOTH device address is known to be a public address the 338 "Universal/Local" bit can be set to 1. 340 As defined in RFC 4291 [RFC4291], the IPv6 link-local address for a 341 BT-LE node is formed by appending the IID, to the prefix FE80::/64, 342 as depicted in Figure 4. 344 10 bits 54 bits 64 bits 345 +----------+-----------------+----------------------+ 346 |1111111010| zeros | Interface Identifier | 347 +----------+-----------------+----------------------+ 349 Figure 4: IPv6 link-local address in BT-LE 351 The tool for a 6LBR to obtain an IPv6 prefix for numbering the BT-LE 352 network is out of scope of this document, but can be, for example, 353 accomplished via DHCPv6 Prefix Delegation [RFC3633] or by using 354 Unique Local IPv6 Unicast Addresses (ULA) [RFC4193]. Due to the link 355 model of the BT-LE (see Section 2.2) the 6LBR MUST set the "on-link" 356 flag (L) to zero in the Prefix Information Option [RFC4861]. This 357 will cause 6LNs to always send packets to the 6LBR, including the 358 case when the destination is another 6LN using the same prefix. 360 3.2.2. Neighbor discovery 362 'Neighbor Discovery Optimization for IPv6 over Low-Power Wireless 363 Personal Area Networks (6LoWPANs)' [RFC6775] describes the neighbor 364 discovery approach as adapted for use in several 6LoWPAN topologies, 365 including the mesh topology. BT-LE does not support mesh networks 366 and hence only those aspects that apply to a star topology are 367 considered. 369 The following aspects of the Neighbor Discovery optimizations 370 [RFC6775] 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 [RFC6775]. 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 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 548 Requirement Levels", BCP 14, RFC 2119, March 1997. 550 [RFC2464] Crawford, M., "Transmission of IPv6 Packets over Ethernet 551 Networks", RFC 2464, December 1998. 553 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 554 Architecture", RFC 4291, February 2006. 556 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 557 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 558 September 2007. 560 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 561 Address Autoconfiguration", RFC 4862, September 2007. 563 [RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler, 564 "Transmission of IPv6 Packets over IEEE 802.15.4 565 Networks", RFC 4944, September 2007. 567 [RFC6282] Hui, J. and P. Thubert, "Compression Format for IPv6 568 Datagrams over IEEE 802.15.4-Based Networks", RFC 6282, 569 September 2011. 571 [RFC6775] Shelby, Z., Chakrabarti, S., Nordmark, E., and C. Bormann, 572 "Neighbor Discovery Optimization for IPv6 over Low-Power 573 Wireless Personal Area Networks (6LoWPANs)", RFC 6775, 574 November 2012. 576 8.2. Informative References 578 [IEEE802-2001] 579 Institute of Electrical and Electronics Engineers (IEEE), 580 "IEEE 802-2001 Standard for Local and Metropolitan Area 581 Networks: Overview and Architecture", 2002. 583 [RFC3610] Whiting, D., Housley, R., and N. Ferguson, "Counter with 584 CBC-MAC (CCM)", RFC 3610, September 2003. 586 [RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic 587 Host Configuration Protocol (DHCP) version 6", RFC 3633, 588 December 2003. 590 [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast 591 Addresses", RFC 4193, October 2005. 593 [RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy 594 Extensions for Stateless Address Autoconfiguration in 595 IPv6", RFC 4941, September 2007. 597 Appendix A. BLUETOOTH Low Energy fragmentation and L2CAP Modes 599 This section provides an overview of Fragmentation and Recombination 600 (FAR) method and L2CAP modes in BT-LE. FAR is an L2CAP mechanism, in 601 which an L2CAP entity can take the (large) upper layer PDU, prepend 602 the L2CAP header (4 bytes in the Basic L2CAP mode) and break the 603 resulting L2CAP PDU into fragments which can then be directly 604 encapsulated into Data channel PDUs. There are bits in the Data 605 channel PDUs which identify whether the payload is a complete L2CAP 606 PDU or the first of a set of fragments, or one of the rest of the 607 fragments. 609 There are five L2CAP modes defined in the BT 4.0 spec. These modes 610 are: Retransmission Mode (a Go-Back-N mechanism is used), Enhanced 611 Retransmission Mode (includes selective NAK among others), Flow 612 Control Mode (PDUs are numbered, but there are no retransmissions), 613 Streaming Mode (PDUs are numbered, but there are no ACKs of any kind) 614 and Basic L2CAP Mode. 616 Appendix B. BLUETOOTH Low Energy L2CAP Channel ID Usage for 6LoWPAN/ 617 IPv6 619 The BT-LE Logical Link Control and Adaptation Protocol (L2CAP) uses 620 Channel Identifiers (IDs) to distinguish the upper layer protocol 621 carried on top of it. Two devices exchanging IPv6/6LoWPAN packets 622 need to use a common Channel ID to be able to send and receive the 623 packets correctly over L2CAP. It is also important that they avoid 624 using Channel ID's that conflict with other L2CAP usages. For the 625 initial use of IPv6/6LoWPAN over BT-LE L2CAP, implementers are 626 recommended to use Channel ID 0x3E from the BLUETOOTH Special 627 Interest Group reserved space (BLUETOOTH 4.0 Logical Link Control and 628 Adaptation Protocol Specification -part, table 2.1 [BTCorev4.0]). As 629 the IPv6/6LoWPAN use becomes more widely adopted, the BT SIG may 630 allocate 0x3E or some other Channel ID exclusively for IPv6/6LoWPAN. 631 Any such BT SIG allocation will deprecate the recommendation given in 632 this Appendix, and a new RFC will be published at the time of 633 allocation that will update this RFC and specify the allocated value. 634 The initial implementers are thus recommended to keep their Channel 635 ID usage capability flexible to potential future changes. 637 Authors' Addresses 639 Johanna Nieminen (editor) 640 Nokia 641 Itaemerenkatu 11-13 642 FI-00180 Helsinki 643 Finland 645 Email: johannamaria.nieminen@gmail.com 647 Teemu Savolainen (editor) 648 Nokia 649 Hermiankatu 12 D 650 FI-33720 Tampere 651 Finland 653 Email: teemu.savolainen@nokia.com 655 Markus Isomaki 656 Nokia 657 Keilalahdentie 2-4 658 FI-02150 Espoo 659 Finland 661 Email: markus.isomaki@nokia.com 663 Basavaraj Patil 664 6021 Connection drive 665 Irving, TX 75039 666 USA 668 Email: bpatil@ovi.com 670 Zach Shelby 671 Sensinode 672 Hallituskatu 13-17D 673 FI-90100 Oulu 674 Finland 676 Email: zach.shelby@sensinode.com 677 Carles Gomez 678 Universitat Politecnica de Catalunya/i2CAT 679 C/Esteve Terradas, 7 680 Castelldefels 08860 681 Spain 683 Email: carlesgo@entel.upc.edu