idnits 2.17.1 draft-ietf-6lowpan-btle-08.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 (June 26, 2012) is 4315 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'RFC 6282' is mentioned on line 375, but not defined == Missing Reference: 'RFC 4941' is mentioned on line 335, but not defined ** Obsolete undefined reference: RFC 4941 (Obsoleted by RFC 8981) == Outdated reference: A later version (-21) exists of draft-ietf-6lowpan-nd-18 -- Possible downref: Non-RFC (?) normative reference: ref. 'IEEE802-2001' -- Obsolete informational reference (is this intentional?): RFC 4941 (Obsoleted by RFC 8981) Summary: 1 error (**), 0 flaws (~~), 4 warnings (==), 3 comments (--). 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: December 28, 2012 M. Isomaki 5 Nokia 6 Z. Shelby 7 Sensinode 8 C. Gomez 9 Universitat Politecnica de 10 Catalunya/i2CAT 11 June 26, 2012 13 Transmission of IPv6 Packets over Bluetooth Low Energy 14 draft-ietf-6lowpan-btle-08 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 December 28, 2012. 47 Copyright Notice 48 Copyright (c) 2012 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. Bluetooth Low Energy . . . . . . . . . . . . . . . . . . . . . 3 65 2.1. Bluetooth Low Energy stack . . . . . . . . . . . . . . . . 4 66 2.2. Link layer roles and topology . . . . . . . . . . . . . . 4 67 2.3. BT-LE device addressing . . . . . . . . . . . . . . . . . 5 68 2.4. BT-LE packets sizes and MTU . . . . . . . . . . . . . . . 5 69 3. Specification of IPv6 over Bluetooth Low Energy . . . . . . . 6 70 3.1. Protocol stack . . . . . . . . . . . . . . . . . . . . . . 6 71 3.2. Link model . . . . . . . . . . . . . . . . . . . . . . . . 7 72 3.2.1. Stateless address autoconfiguration . . . . . . . . . 7 73 3.2.2. Neighbor discovery . . . . . . . . . . . . . . . . . . 8 74 3.2.3. Header compression . . . . . . . . . . . . . . . . . . 9 75 3.2.4. Unicast and Multicast address mapping . . . . . . . . 10 76 3.3. Internet connectivity scenarios . . . . . . . . . . . . . 10 77 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 78 5. Security Considerations . . . . . . . . . . . . . . . . . . . 11 79 6. Additional contributors . . . . . . . . . . . . . . . . . . . 11 80 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11 81 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 82 8.1. Normative References . . . . . . . . . . . . . . . . . . . 11 83 8.2. Informative References . . . . . . . . . . . . . . . . . . 12 84 Appendix A. Bluetooth Low Energy fragmentation and L2CAP Modes . 13 85 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 87 1. Introduction 89 Bluetooth Low Energy (BT-LE) is a radio technology targeted for 90 devices that operate with coin cell batteries or minimalistic power 91 sources, which means that low power consumption is essential. BT-LE 92 is an especially attractive technology for Internet of Things 93 applications, such as health monitors, environmental sensing, 94 proximity applications and many others. 96 Considering the potential for the exponential growth in the number of 97 sensors and Internet connected devices and things, IPv6 is an ideal 98 protocol due to the large address space it provides. In addition, 99 IPv6 provides tools for autoconfiguration, which is particularly 100 suitable for sensor network applications and nodes which have very 101 limited processing power or a full-fledged operating system. 103 [RFC4944] specifies the transmission of IPv6 over IEEE 802.15.4. The 104 Bluetooth Low Energy link in many respects has similar 105 characteristics to that of IEEE 802.15.4. Many of the mechanisms 106 defined in [RFC4944] can be applied to the transmission of IPv6 on 107 Bluetooth Low Energy links. This document specifies the details of 108 IPv6 transmission over Bluetooth Low Energy links. 110 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 111 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 112 document are to be interpreted as described in RFC 2119 [RFC2119]. 114 The terms 6LN, 6LR and 6LBR are defined as in [I-D.ietf-6lowpan-nd]. 116 2. Bluetooth Low Energy 118 BT-LE is designed for transferring small amounts of data infrequently 119 at modest data rates at a very low cost per bit. Bluetooth Special 120 Interest Group [BT-SIG] has introduced two trademarks, Bluetooth 121 Smart for single-mode devices (a device that only supports BT-LE) and 122 Bluetooth Smart Ready for dual-mode devices. In the rest of the 123 draft, the term BT-LE refers to both types of devices. 125 BT-LE is an integral part of the BT 4.0 specification [BTCorev4.0]. 126 Devices such as mobile phones, notebooks, tablets and other handheld 127 computing devices which include BT 4.0 chipsets also have the low- 128 energy functionality of Bluetooth. BT-LE is also included in many 129 different types of accessories that collaborate with mobile devices 130 such as phones, tablets and notebook computers. An example of a use 131 case for a BT-LE accessory is a heart rate monitor that sends data 132 via the mobile phone to a server on the Internet. 134 2.1. Bluetooth Low Energy stack 136 The lower layer of the BT-LE stack consists of the Physical (PHY) and 137 the Link Layer (LL). The Physical Layer transmits and receives the 138 actual packets. The Link Layer is responsible for providing medium 139 access, connection establishment, error control and flow control. 140 The upper layer consists of the Logical Link Control and Adaptation 141 Protocol (L2CAP), Generic Attribute protocol (GATT) and Generic 142 Access Profile (GAP) as shown in Figure 1. GATT and BT-LE profiles 143 together enable the creation of applications in a standardized way 144 without using IP. L2CAP provides multiplexing capability by 145 multiplexing the data channels from the above layers. L2CAP also 146 provides fragmentation and reassembly for large data packets. 148 +----------------------------------------+------------------+ 149 | Applications | 150 +----------------------------------------+------------------+ 151 | Generic Attribute Profile | Generic Access | 152 +----------------------------------------+ Profile | 153 | Attribute Protocol |Security Manager | | 154 +--------------------+-------------------+------------------+ 155 | Logical Link Control and Adaptation | 156 +--------------------+-------------------+------------------+ 157 | Host Controller Interface | 158 +--------------------+-------------------+------------------+ 159 | Link Layer | Direct Test Mode | 160 +--------------------+-------------------+------------------+ 161 | Physical Layer | 162 +--------------------+-------------------+------------------+ 164 Figure 1: BT-LE Protocol Stack 166 2.2. Link layer roles and topology 168 BT-LE defines two Link Layer roles: the Master Role and the Slave 169 Role. A device in the Master Role, which is called master, can 170 manage multiple simultaneous connections with a number of devices in 171 the Slave Role, called slaves. A slave can only be connected to a 172 single master. Hence, a BT-LE network (i.e. a BT-LE piconet) follows 173 a star topology. 175 [BTLE-Slave]-----\ /-----[BTLE-Slave] 176 \ / 177 [BTLE-Slave]-----/[BTLE-Master]/-----[BTLE-Slave] 178 / \ 179 [BTLE-Slave]-----/ \-----[BTLE-Slave] 181 Figure 2: BT-LE Star Topology 183 A master is assumed to be less constrained than a slave. Hence, 184 master and slave can act as 6LoWPAN Border Router (6LBR) and host, 185 respectively. 187 In BT-LE, communication only takes place between a master and a 188 slave. Hence, in a BT-LE network using IP, a radio hop is equivalent 189 to an IP link and vice versa. 191 2.3. BT-LE device addressing 193 Every BT-LE device is identified by a unique 48 bit Bluetooth Device 194 Address (BD_ADDR). A Bluetooth Smart device such as a sensor may use 195 a public (obtained from IEEE Registration Authority) or a random 196 device address (generated internally). The public address is created 197 according to the IEEE 802-2001 standard [IEEE802-2001] and using a 198 valid Organizationally Unique Identifier (OUI) obtained from the IEEE 199 Registration Authority. This specification mandates that the 200 Bluetooth Device Address MUST be a public address. 202 2.4. BT-LE packets sizes and MTU 204 Maximum size of the payload in the BT-LE data channel PDU is 27 205 bytes. Depending on the L2CAP mode in use, the amount of data 206 available for transporting IP bytes in the single BT-LE data channel 207 PDU ranges between 19 and 27 octets. For power efficient 208 communication between two BT-LE devices, data and its header should 209 fit in a single BT-LE data channel PDU. However, IPv6 requires 210 support for an MTU of 1280 bytes. An inherent function of the BT-LE 211 L2CAP layer, called Fragmentation and Recombination (FAR), can assist 212 in transferring IPv6 packets that do not fit in a single BT-LE data 213 channel PDU. 215 The maximum IP datagram size that can be transported by L2CAP depends 216 on the L2CAP mode. The Basic L2CAP Mode allows a maximum payload 217 size (i.e. IP datagram size) of 65535 bytes per L2CAP PDU. The rest 218 of the L2CAP modes allow a maximum payload size that ranges between 219 65527 and 65533 bytes per L2CAP PDU. Appendix A describes FAR 220 operation and five L2CAP Modes. This specification requires that FAR 221 functionality MUST be provided in the L2CAP layer up to the IPv6 222 minimum MTU of 1280 bytes. The corresponding L2CAP Mode MUST be 223 Basic Mode. Since FAR in BT-LE is a function of the L2CAP layer, 224 fragmentation functionality as defined in [RFC4944] MUST NOT be used 225 in BT-LE networks. 227 3. Specification of IPv6 over Bluetooth Low Energy 229 BT-LE technology sets strict requirements for low power consumption 230 and thus limits the allowed protocol overhead. 6LoWPAN standards 231 [RFC4944], [I-D.ietf-6lowpan-nd] and [RFC6282] provide useful generic 232 functionality like header compression, link-local IPv6 addresses, 233 Neighbor Discovery and stateless IP-address autoconfiguration for 234 reducing the overhead in 802.15.4 networks. This functionality can 235 be partly applied to BT-LE. 237 A significant difference between IEEE 802.15.4 and BT-LE is that the 238 former supports both star and mesh topology (and requires a routing 239 protocol), whereas BT-LE does not currently support the formation of 240 multihop networks. In consequence, the mesh header defined in 241 [RFC4944] for mesh under routing MUST NOT be used in BT-LE networks. 242 In addition, a BT-LE device MUST NOT play the role of a 6LoWPAN 243 Router (6LR). 245 3.1. Protocol stack 247 In order to enable transmission of IPv6 packets over BT-LE, a new 248 fixed L2CAP channel ID MUST be reserved for IPv6 traffic by the BT- 249 SIG. A request for allocation of a new fixed channel ID for IPv6 250 traffic by the BT-SIG should be submitted through the liaison process 251 or formal communique from the 6lowpan chairs and respective area 252 directors. Until a channel ID is allocated by BT-SIG, the channel ID 253 0x0007 is recommended for experimentation. Once the channel ID is 254 allocated, the allocated value MUST be used. Figure 3 illustrates 255 IPv6 over BT-LE stack. 257 +-------------------+ 258 | UDP/TCP | 259 +-------------------+ 260 | IPv6 | 261 +-------------------+ 262 | 6LoWPAN adapted | 263 | to BT-LE | 264 +-------------------+ 265 | BT-LE L2CAP | 266 +-------------------+ 267 | BT-LE Link Layer | 268 +-------------------+ 269 | BT-LE Physical | 270 +-------------------+ 272 Figure 3: IPv6 over BT-LE Stack 274 3.2. Link model 276 The concept of IP link (layer 3) and the physical link (combination 277 of PHY and MAC) needs to be clear and the relationship has to be well 278 understood in order to specify the addressing scheme for transmitting 279 IPv6 packets over the BT-LE link. [RFC4861] defines a link as "a 280 communication facility or medium over which nodes can communicate at 281 the link layer, i.e., the layer immediately below IP." 283 In the case of BT-LE, L2CAP is an adaptation layer that supports the 284 transmission of IPv6 packets. L2CAP also provides multiplexing 285 capability in addition to FAR functionality. This draft assumes the 286 IPv6 header compression format specified in [RFC 6282]. It is also 287 assumed that the IPv6 payload length can be inferred from the L2CAP 288 header length and also assumes that IPv6 addresses assigned to 289 6LoWPAN interfaces are formed with an IID derived directly from the 290 48-bit Bluetooth device addresses, as described in subsection 3.2.1. 292 The BT-LE link between two communicating nodes can be considered to 293 be a point-to-point or point-to-multipoint link. When one of the 294 communicating nodes is in the role of a master, then the link can be 295 viewed as a point-to-multipoint link. 297 When a host connects to another BT-LE device the link is up and IP 298 address configuration and transmission can occur. 300 3.2.1. Stateless address autoconfiguration 302 A BT-LE 6LN performs stateless address autoconfiguration as per 303 [RFC4862]. The 64 bit Interface Identifier (IID) for a BT-LE 304 interface is formed from the 48-bit unique public Bluetooth device 305 address, [Section 2.3] as per the "IPv6 over Ethernet" specification 306 [RFC2464]. A BT-LE 6LN SHOULD utilize this EUI-64 address for 307 stateless address autoconfiguration. The 48-bit public bluetooth 308 address is globally unique and provided by the IEEE registration 309 authority. Hence the "Universal/Local" (U/L) bit MUST be set to 0. 311 The IPv6 link-local address [RFC4291] for a BT-LE node is formed by 312 appending the IID, as defined above, to the prefix FE80::/64, as 313 depicted in Figure 4. 315 The tool for a gateway to obtain an IPv6 prefix for numbering the 316 BT-LE network is out of scope of this document, but can for example 317 be accomplished via DHCPv6 Prefix Delegation. The used IPv6 prefix 318 may change due to the gateway^1s movement. 320 3.2.2. Neighbor discovery 322 [I-D.ietf-6lowpan-nd] describes the neighbor discovery approach as 323 adapted for use in several 6LoWPAN topologies, including the mesh 324 topology. BT-LE does not support mesh networks and hence only those 325 aspects of the [I-D.ietf-6lowpan-nd] that apply to a star topology 326 are considered. 328 The following aspects of 6lowpan-nd are applicable to BT-LE 6LNS: 330 1. A BT-LE 6LN MUST register its address with the router by sending 331 a NS message with the ARO option and process the NA accordingly. The 332 NS with the ARO option SHOULD be sent irrespective of whether the IID 333 is derived from the unique 48 bit BT-LE device address or the IID is 334 a random value that is generated as per the privacy extensions for 335 stateless address autoconfiguration [RFC4941]. Although [RFC 4941] 336 permits the use of deprecated addresses for old connections, in this 337 draft we mandate that one interface MUST NOT use more than one IID. 339 2. Sending a Router solicitation (RS) and processing Router 340 advertisements by BT-LE 6LNs MUST follow Sections 5.3 and 5.4 341 respectvely of [I-D.ietf-6lowpan-nd]. 343 10 bits 54 bits 64 bits 344 +----------+-----------------+----------------------+ 345 |1111111010| zeros | Interface Identifier | 346 +----------+-----------------+----------------------+ 348 Figure 4: IPv6 link-local address in BT-LE 350 3.2.3. Header compression 352 This document assumes [RFC6282], which specifies the compression 353 format for IPv6 datagrams on top of IEEE 802.15.4, as the basis for 354 IPv6 header compression on top of BT-LE. It is required that all 355 headers MUST be compressed according to HC base encoding. In BT-LE 356 the star topology structure can be exploited in order to provide a 357 mechanism for IID compression. The following text describes the 358 principles of IPv6 address compression on top of BT-LE. 360 In a link-local communication, both the IPv6 source and destination 361 addresses MUST be elided, since the device knows that the packet is 362 destined for it even if the packet does not have destination IPv6 363 address. On the other hand, a node SHALL learn the IID of the other 364 endpoint of each L2CAP connection it participates in. By exploiting 365 this information, a node that receives a data channel PDU containing 366 an IPv6 packet (or a part of it) can infer the corresponding IPv6 367 source address. The device MUST maintain a Neighbor Cache, in which 368 the entries include both the IID of the neighbor and the Device 369 Address that identifies the neighbor. 371 When a BT-LE slave transmits an IPv6 packet to a remote destination 372 using global IPv6 addresses, if a context is defined for the prefix 373 of the slave global IPv6 address, the slave MUST indicate this 374 context in the corresponding source fields of the compressed IPv6 375 header as per Section 3.2.1 of [RFC 6282], and MUST elide the IPv6 376 source address. In this case, the 6LBR/master can infer the elided 377 IPv6 source address since 1) the master/6LBR has previously assigned 378 the prefix to the slaves; and 2) the master/6LBR maintains a Neighbor 379 Cache that relates the Device Address and the IID of the 380 corresponding slave. If a context is defined for the IPv6 381 destination address, the slave MUST also indicate this context in the 382 corresponding destination fields of the compressed IPv6 header, and 383 MUST elide the prefix of the destination IPv6 address. In that case, 384 the 6LBR/master can infer the elided destination prefix by using the 385 context. 387 When a master/6LBR receives an IPv6 packet sent by a remote node 388 outside the BT-LE network, and the destination of the packet is a 389 slave, if a context is defined for the prefix of the slave global 390 IPv6 address, the master/6LBR MUST indicate this context in the 391 corresponding destination fields of the compressed IPv6 header, and 392 MUST elide the IPv6 destination address of the packet before 393 forwarding it to the slave. If a context is defined for the prefix 394 of the IPv6 source address, the master/6LBR MUST indicate this 395 context in the source fields of the compressed IPv6 header, and MUST 396 elide that prefix as well. 398 3.2.4. Unicast and Multicast address mapping 400 The BT-LE link layer does not support multicast. Hence traffic is 401 always unicast between two BT-LE devices. Even in the case where a 402 master is attached to multiple slave BT-LE devices, the master device 403 cannot do a multicast to all the connected slave devices. If the 404 master device needs to send a multicast packet to all its slave 405 devices, it has to replicate the packet and unicast it on each link. 406 However, this may not be energy-efficient and particular care must be 407 taken if the master is battery-powered. In the opposite direction, a 408 slave can only transmit data to a single destination (i.e. the 409 master). Hence, if a slave transmits an IPv6 multicast packet, the 410 slave can unicast the corresponding BT-LE packet to the master. It 411 is required that the master MUST provide a table for mapping 412 different types of multicast addresses (all-nodes, all-routers and 413 solicited-node multicast addresses) to the corresponding IIDs and 414 Device Addresses. 416 3.3. Internet connectivity scenarios 418 In a typical scenario, the BT-LE network is connected to the 419 Internet. 421 h ____________ 422 \ / \ 423 h ---- 6LBR --- | Internet | 424 / \____________/ 425 h 426 h: host 427 <-- BT-LE --> 6LBR: 6LoWPAN Border Router 429 Figure 5: BT-LE network connected to the Internet 431 In some scenarios, the BT-LE network may transiently or permanently 432 be an isolated network. 434 h h h: host 435 \ / 6LBR: 6LoWPAN Border Router 436 h --- 6LBR -- h 437 / \ 438 h h 440 Figure 6: Isolated BT-LE network 442 Host-to-master and master-to-host communication MUST use the same 443 mechanisms as would be used in global IPv6 communications. The 444 gateway is used to route the packets to one of its slaves. 446 4. IANA Considerations 448 While there are no actions for IANA, we do expect BT SIG to allocate 449 an L2CAP channel ID (see Section 3.1). 451 5. Security Considerations 453 The transmission of IPv6 over BT-LE links has similar requirements 454 and concerns for security as for IEEE 802.15.4. IPv6 over BT-LE 455 SHOULD be protected by using BT-LE Link Layer security. 457 BT-LE Link Layer supports encryption and authentication by using the 458 Counter with CBC-MAC (CCM) mechanism [RFC3610] and a 128-bit AES 459 block cipher. Upper layer security mechanisms may exploit this 460 functionality when it is available. (Note: CCM does not consume 461 bytes from the maximum per-packet L2CAP data size, since the link 462 layer data unit has a specific field for them when they are used.) 464 Key management in BT-LE is provided by the Security Manager Protocol 465 (SMP). 467 6. Additional contributors 469 Kanji Kerai, Jari Mutikainen, David Canfeng-Chen and Minjun Xi from 470 Nokia have contributed significantly to this document. 472 7. Acknowledgements 474 Samita Chakrabarti and Erik Nordmark have provided valuable feedback 475 for this draft. 477 8. References 479 8.1. Normative References 481 [BTCorev4.0] 482 "Bluetooth Core Specification v4.0, http:// 483 www.bluetooth.org/Technical/Specifications/adopted.htm". 485 [I-D.ietf-6lowpan-nd] 486 Shelby, Z., Chakrabarti, S., and E. Nordmark, "Neighbor 487 Discovery Optimization for Low Power and Lossy Networks 488 (6LoWPAN)", draft-ietf-6lowpan-nd-18 (work in progress), 489 October 2011. 491 [IEEE802-2001] 492 "IEEE 802-2001 standard, 493 http://standards.ieee.org/findstds/standard/ 494 802-2001.html". 496 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 497 Requirement Levels", BCP 14, RFC 2119, March 1997. 499 [RFC2464] Crawford, M., "Transmission of IPv6 Packets over Ethernet 500 Networks", RFC 2464, December 1998. 502 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 503 Architecture", RFC 4291, February 2006. 505 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 506 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 507 September 2007. 509 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 510 Address Autoconfiguration", RFC 4862, September 2007. 512 [RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler, 513 "Transmission of IPv6 Packets over IEEE 802.15.4 514 Networks", RFC 4944, September 2007. 516 [RFC6282] Hui, J. and P. Thubert, "Compression Format for IPv6 517 Datagrams over IEEE 802.15.4-Based Networks", RFC 6282, 518 September 2011. 520 8.2. Informative References 522 [BT-SIG] "Bluetooth Special Interest Group (BT-SIG), 523 http://www.bluetooth.org". 525 [RFC3610] Whiting, D., Housley, R., and N. Ferguson, "Counter with 526 CBC-MAC (CCM)", RFC 3610, September 2003. 528 [RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy 529 Extensions for Stateless Address Autoconfiguration in 530 IPv6", RFC 4941, September 2007. 532 Appendix A. Bluetooth Low Energy fragmentation and L2CAP Modes 534 This section provides an overview of Fragmentation and Recombination 535 (FAR) method and L2CAP modes in Bluetooth Low Energy. FAR is an 536 L2CAP mechanism, in which an L2CAP entity can take the (large) upper 537 layer PDU, prepend the L2CAP header (4 bytes in the Basic L2CAP mode) 538 and break the resulting L2CAP PDU into fragments which can then be 539 directly encapsulated into Data channel PDUs. There are bits in the 540 Data channel PDUs which identify whether the payload is a complete 541 L2CAP PDU or the first of a set of fragments, or one of the rest of 542 the fragments. 544 There are five L2CAP modes defined in the BT 4.0 spec. These modes 545 are: Retransmission Mode (a Go-Back-N mechanism is used), Enhanced 546 Retransmission Mode (includes selective NAK among others), Flow 547 Control Mode (PDUs are numbered, but there are no retransmissions), 548 Streaming Mode (PDUs are numbered, but there are no ACKs of any kind) 549 and Basic L2CAP Mode. 551 Authors' Addresses 553 Johanna Nieminen (editor) 554 Nokia 555 Itaemerenkatu 11-13 556 FI-00180 Helsinki 557 Finland 559 Email: johanna.1.nieminen@nokia.com 561 Basavaraj Patil 562 Nokia 563 6021 Connection drive 564 Irving, TX 75039 565 USA 567 Email: basavaraj.patil@nokia.com 569 Teemu Savolainen 570 Nokia 571 Hermiankatu 12 D 572 FI-33720 Tampere 573 Finland 575 Email: teemu.savolainen@nokia.com 576 Markus Isomaki 577 Nokia 578 Keilalahdentie 2-4 579 FI-02150 Espoo 580 Finland 582 Email: markus.isomaki@nokia.com 584 Zach Shelby 585 Sensinode 586 Hallituskatu 13-17D 587 FI-90100 Oulu 588 Finland 590 Email: zach.shelby@sensinode.com 592 Carles Gomez 593 Universitat Politecnica de Catalunya/i2CAT 594 C/Esteve Terradas, 7 595 Castelldefels 08860 596 Spain 598 Email: carlesgo@entel.upc.edu