idnits 2.17.1 draft-ietf-6lowpan-btle-09.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 30, 2012) is 4286 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 384, but not defined == Missing Reference: 'RFC 4941' is mentioned on line 339, but not defined ** Obsolete undefined reference: RFC 4941 (Obsoleted by RFC 8981) == Missing Reference: 'RFC3610' is mentioned on line 475, but not defined == Outdated reference: A later version (-21) exists of draft-ietf-6lowpan-nd-19 -- Possible downref: Non-RFC (?) normative reference: ref. 'IEEE802-2001' -- 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: 1 error (**), 0 flaws (~~), 5 warnings (==), 4 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: January 31, 2013 M. Isomaki 5 Nokia 6 Z. Shelby 7 Sensinode 8 C. Gomez 9 Universitat Politecnica de 10 Catalunya/i2CAT 11 July 30, 2012 13 Transmission of IPv6 Packets over Bluetooth Low Energy 14 draft-ietf-6lowpan-btle-09 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 currently specified in revision 4.0 of the Bluetooth specifications 26 (Bluetooth 4.0). This document describes how IPv6 is transported 27 over Bluetooth Low Energy using 6LoWPAN techniques. 29 Status of this Memo 31 This Internet-Draft is submitted in full conformance with the 32 provisions of BCP 78 and BCP 79. 34 Internet-Drafts are working documents of the Internet Engineering 35 Task Force (IETF). Note that other groups may also distribute 36 working documents as Internet-Drafts. The list of current Internet- 37 Drafts is at http://datatracker.ietf.org/drafts/current/. 39 Internet-Drafts are draft documents valid for a maximum of six months 40 and may be updated, replaced, or obsoleted by other documents at any 41 time. It is inappropriate to use Internet-Drafts as reference 42 material or to cite them other than as "work in progress." 44 This Internet-Draft will expire on January 31, 2013. 46 Copyright Notice 47 Copyright (c) 2012 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents 52 (http://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with respect 55 to this document. Code Components extracted from this document must 56 include Simplified BSD License text as described in Section 4.e of 57 the Trust Legal Provisions and are provided without warranty as 58 described in the Simplified BSD License. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 63 2. Bluetooth Low Energy . . . . . . . . . . . . . . . . . . . . . 3 64 2.1. Bluetooth Low Energy stack . . . . . . . . . . . . . . . . 4 65 2.2. Link layer roles and topology . . . . . . . . . . . . . . 4 66 2.3. BT-LE device addressing . . . . . . . . . . . . . . . . . 5 67 2.4. BT-LE packets sizes and MTU . . . . . . . . . . . . . . . 5 68 3. Specification of IPv6 over Bluetooth Low Energy . . . . . . . 6 69 3.1. Protocol stack . . . . . . . . . . . . . . . . . . . . . . 6 70 3.2. Link model . . . . . . . . . . . . . . . . . . . . . . . . 7 71 3.2.1. Stateless address autoconfiguration . . . . . . . . . 8 72 3.2.2. Neighbor discovery . . . . . . . . . . . . . . . . . . 8 73 3.2.3. Header compression . . . . . . . . . . . . . . . . . . 9 74 3.2.4. Unicast and Multicast address mapping . . . . . . . . 10 75 3.3. Internet connectivity scenarios . . . . . . . . . . . . . 10 76 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 77 5. Security Considerations . . . . . . . . . . . . . . . . . . . 11 78 6. Additional contributors . . . . . . . . . . . . . . . . . . . 12 79 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12 80 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 81 8.1. Normative References . . . . . . . . . . . . . . . . . . . 12 82 8.2. Informative References . . . . . . . . . . . . . . . . . . 13 83 Appendix A. Bluetooth Low Energy fragmentation and L2CAP Modes . 13 84 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 86 1. Introduction 88 Bluetooth Low Energy (BT-LE) is a radio technology targeted for 89 devices that operate with coin cell batteries or minimalistic power 90 sources, which means that low power consumption is essential. BT-LE 91 is an especially attractive technology for Internet of Things 92 applications, such as health monitors, environmental sensing, 93 proximity applications and many others. 95 Considering the potential for the exponential growth in the number of 96 sensors and Internet connected devices and things, IPv6 is an ideal 97 protocol due to the large address space it provides. In addition, 98 IPv6 provides tools for stateless address autoconfiguration, which is 99 particularly suitable for sensor network applications and nodes which 100 have very limited processing power or lack a full-fledged operating 101 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 has introduced two trademarks, Bluetooth Smart for 121 single-mode devices (a device that only supports BT-LE) and Bluetooth 122 Smart Ready for dual-mode devices. In the rest of the draft, the 123 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. This specification primarily addresses the 174 situation where the BT-LE Slave is a host but not a router at the IP 175 level. 177 [BTLE-Slave]-----\ /-----[BTLE-Slave] 178 \ / 179 [BTLE-Slave]-----/[BTLE-Master]/-----[BTLE-Slave] 180 / \ 181 [BTLE-Slave]-----/ \-----[BTLE-Slave] 183 Figure 2: BT-LE Star Topology 185 A master is assumed to be less constrained than a slave. Hence, 186 master and slave can act as 6LoWPAN Border Router (6LBR) and host, 187 respectively. 189 In BT-LE, communication only takes place between a master and a 190 slave. Hence, in a BT-LE network using IP, a radio hop is equivalent 191 to an IP link and vice versa. 193 2.3. BT-LE device addressing 195 Every BT-LE device is identified by a unique 48 bit Bluetooth Device 196 Address (BD_ADDR). A Bluetooth Smart device such as a sensor can use 197 a public or a random device address (generated internally). The 198 public address is created according to the IEEE 802-2001 standard 199 [IEEE802-2001] and using a valid Organizationally Unique Identifier 200 (OUI) obtained from the IEEE Registration Authority. 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. 222 3. Specification of IPv6 over Bluetooth Low Energy 224 BT-LE technology sets strict requirements for low power consumption 225 and thus limits the allowed protocol overhead. 6LoWPAN standards 226 [RFC4944], [I-D.ietf-6lowpan-nd] and [RFC6282] provide useful generic 227 functionality like header compression [Section 3.2.3], link-local 228 IPv6 addresses, Neighbor Discovery [Section 3.2.2] and stateless IP- 229 address autoconfiguration [Section 3.2.1] for reducing the overhead 230 in 802.15.4 networks. This functionality can be partly applied to 231 BT-LE. 233 A significant difference between IEEE 802.15.4 and BT-LE is that the 234 former supports both star and mesh topology (and requires a routing 235 protocol), whereas BT-LE does not currently support the formation of 236 multihop networks at the link layer. In consequence, the mesh header 237 defined in [RFC4944] for mesh under routing MUST NOT be used in BT-LE 238 networks. In addition, a BT-LE device MUST NOT play the role of a 239 6LoWPAN Router (6LR). 241 3.1. Protocol stack 243 In order to enable transmission of IPv6 packets over BT-LE, a new 244 fixed L2CAP channel ID is being reserved for IPv6 traffic by the BT- 245 SIG. A request for allocation of a new fixed channel ID for IPv6 246 traffic by the BT-SIG should be submitted through the liaison process 247 or formal communique from the 6lowpan chairs and respective area 248 directors. Until a channel ID is allocated by BT-SIG, the channel ID 249 0x0007 is recommended for experimentation. Once the channel ID is 250 allocated, the allocated value MUST be used. Figure 3 illustrates 251 IPv6 over BT-LE stack. UDP/TCP are provided as examples of a 252 transport protocol, but the stack can be used by other transport 253 protocols as well. 255 +-------------------+ 256 | UDP/TCP | 257 +-------------------+ 258 | IPv6 | 259 +-------------------+ 260 | 6LoWPAN adapted | 261 | to BT-LE | 262 +-------------------+ 263 | BT-LE L2CAP | 264 +-------------------+ 265 | BT-LE Link Layer | 266 +-------------------+ 267 | BT-LE Physical | 268 +-------------------+ 270 Figure 3: IPv6 over BT-LE Stack 272 3.2. Link model 274 The concept of IP link (layer 3) and the physical link (combination 275 of PHY and MAC) needs to be clear and the relationship has to be well 276 understood in order to specify the addressing scheme for transmitting 277 IPv6 packets over the BT-LE link. [RFC4861] defines a link as "a 278 communication facility or medium over which nodes can communicate at 279 the link layer, i.e., the layer immediately below IP." 281 In the case of BT-LE, L2CAP is an adaptation layer that supports the 282 transmission of IPv6 packets. L2CAP also provides multiplexing 283 capability in addition to FAR functionality. This specification 284 requires that FAR functionality MUST be provided in the L2CAP layer 285 up to the IPv6 minimum MTU of 1280 bytes. The corresponding L2CAP 286 Mode MUST be Basic Mode. Since FAR in BT-LE is a function of the 287 L2CAP layer, fragmentation functionality as defined in [RFC4944] MUST 288 NOT be used in BT-LE networks. This specification also assumes the 289 IPv6 header compression format specified in [RFC 6282]. It is also 290 assumed that the IPv6 payload length can be inferred from the L2CAP 291 header length and also assumes that IPv6 addresses assigned to 292 6LoWPAN interfaces are formed with an IID derived directly from the 293 48-bit Bluetooth device addresses, as described in subsection 3.2.1. 295 The BT-LE link between two communicating nodes can be considered to 296 be a point-to-point or point-to-multipoint link. When one of the 297 communicating nodes is in the role of a master, then the link can be 298 viewed as a point-to-multipoint link. 300 When a host connects to another BT-LE device the link is up and IP 301 address configuration and transmission can occur. 303 3.2.1. Stateless address autoconfiguration 305 A BT-LE 6LN performs stateless address autoconfiguration as per 306 [RFC4862]. This specification mandates that the 64 bit Interface 307 Identifier (IID) for a BT-LE interface MUST be formed using a 308 Bluetooth Device Address that is a 48-bit unique public Bluetooth 309 address, [Section 2.3] as per the "IPv6 over Ethernet" specification 310 [RFC2464]. A BT-LE 6LN node MAY use this EUI-64 based IID or a 311 randomly generated IID [Section 3.2.2] for stateless address 312 autoconfiguration. Since the 48-bit public Bluetooth address is 313 globally unique, the "Universal/Local" (U/L) bit MUST be set to 0. 315 As defined in [RFC4291], the IPv6 link-local address for a BT-LE node 316 is formed by appending the IID, to the prefix FE80::/64, as depicted 317 in Figure 4. 319 The tool for a gateway to obtain an IPv6 prefix for numbering the 320 BT-LE network is out of scope of this document, but can for example 321 be accomplished via DHCPv6 Prefix Delegation [RFC3633]. The used 322 IPv6 prefix may change due to the gateway's movement. 324 3.2.2. Neighbor discovery 326 [I-D.ietf-6lowpan-nd] describes the neighbor discovery approach as 327 adapted for use in several 6LoWPAN topologies, including the mesh 328 topology. BT-LE does not support mesh networks and hence only those 329 aspects of the [I-D.ietf-6lowpan-nd] that apply to a star topology 330 are considered. 332 The following aspects of 6lowpan-nd are applicable to BT-LE 6LNS: 334 1. A BT-LE 6LN MUST register its address with the router by sending 335 a NS message with the ARO option and process the NA accordingly. The 336 NS with the ARO option SHOULD be sent irrespective of whether the IID 337 is derived from the unique 48 bit BT-LE device address or the IID is 338 a random value that is generated as per the privacy extensions for 339 stateless address autoconfiguration [RFC4941]. Although [RFC 4941] 340 permits the use of deprecated addresses for old connections, in this 341 specification we mandate that one interface MUST NOT use more than 342 one IID at any one time. 344 2. Sending a Router solicitation (RS) and processing Router 345 advertisements by BT-LE 6LNs MUST follow Sections 5.3 and 5.4 346 respectively of [I-D.ietf-6lowpan-nd]. 348 10 bits 54 bits 64 bits 349 +----------+-----------------+----------------------+ 350 |1111111010| zeros | Interface Identifier | 351 +----------+-----------------+----------------------+ 353 Figure 4: IPv6 link-local address in BT-LE 355 3.2.3. Header compression 357 Header compression, as defined in [RFC6282], which specifies the 358 compression format for IPv6 datagrams on top of IEEE 802.15.4 is 359 REQUIRED in this document as the basis for IPv6 header compression on 360 top of BT-LE. All headers MUST be compressed according to RFC 6282 361 encoding formats. In BT-LE the star topology structure can be 362 exploited in order to provide a mechanism for IID compression. The 363 following text describes the principles of IPv6 address compression 364 on top of BT-LE. 366 In a link-local communication, both the IPv6 source and destination 367 addresses MUST be elided [RFC6282], since the device knows that the 368 packet is destined for it even if the packet does not have 369 destination IPv6 address. On the other hand, a node SHALL learn the 370 IID of the other endpoint of each L2CAP connection it participates 371 in. By exploiting this information, a node that receives a data 372 channel PDU containing an IPv6 packet (or a part of it) can infer the 373 corresponding IPv6 source address. The device MUST maintain a 374 Neighbor Cache, in which the entries include both the IID of the 375 neighbor and the Device Address that identifies the neighbor. For 376 the type of communication considered in this paragraph, the following 377 settings MUST be used in the IPv6 compressed header: CID=0, SAC=0, 378 SAM=11, DAC=0, DAM=11. 380 When a BT-LE slave transmits an IPv6 packet to a remote destination 381 using global Unicast IPv6 addresses, if a context is defined for the 382 prefix of the slave global IPv6 address, the slave MUST indicate this 383 context in the corresponding source fields of the compressed IPv6 384 header as per Section 3.1 of [RFC 6282], and MUST elide the IPv6 385 source address. For this, the slave MUST use the following settings 386 in the IPv6 compressed header: CID=1, SAC=1, SAM=11. In this case, 387 the 6LBR/master can infer the elided IPv6 source address since 1) the 388 master/6LBR has previously assigned the prefix to the slaves; and 2) 389 the master/6LBR maintains a Neighbor Cache that relates the Device 390 Address and the IID of the corresponding slave. If a context is 391 defined for the IPv6 destination address, the slave MUST also 392 indicate this context in the corresponding destination fields of the 393 compressed IPv6 header, and MUST elide the prefix of the destination 394 IPv6 address. For this, the slave MUST set the DAM field of the 395 compressed IPv6 header as DAM=01 (if the context covers a 64-bit 396 prefix) or as DAM=11 (if the context covers a full, 128-bit address). 397 CID and DAC MUST be set to CID=1 and DAC=1. Note that when a context 398 is defined for the IPv6 destination address, the 6LBR/master can 399 infer the elided destination prefix by using the context. 401 When a master/6LBR receives an IPv6 packet sent by a remote node 402 outside the BT-LE network, and the destination of the packet is a 403 slave, if a context is defined for the prefix of the slave global 404 IPv6 address, the master/6LBR MUST indicate this context in the 405 corresponding destination fields of the compressed IPv6 header, and 406 MUST elide the IPv6 destination address of the packet before 407 forwarding it to the slave. For this, the master/6LBR MUST set the 408 DAM field of the IPv6 compressed header as DAM=11. CID and DAC MUST 409 be set to CID=1 and DAC=1. If a context is defined for the prefix of 410 the IPv6 source address, the master/6LBR MUST indicate this context 411 in the source fields of the compressed IPv6 header, and MUST elide 412 that prefix as well. For this, the master/6LBR MUST set the SAM 413 field of the IPv6 compressed header as SAM=01 (if the context covers 414 a 64-bit prefix) or SAM=11 (if the context covers a full, 128-bit 415 address). CID and SAC MUST be set to CID=1 and SAC=1. 417 3.2.4. Unicast and Multicast address mapping 419 The BT-LE link layer does not support multicast. Hence traffic is 420 always unicast between two BT-LE devices. Even in the case where a 421 master is attached to multiple slave BT-LE devices, the master device 422 cannot do a multicast to all the connected slave devices. If the 423 master device needs to send a multicast packet to all its slave 424 devices, it has to replicate the packet and unicast it on each link. 425 However, this may not be energy-efficient and particular care must be 426 taken if the master is battery-powered. In the opposite direction, a 427 slave can only transmit data to a single destination (i.e. the 428 master). Hence, if a slave transmits an IPv6 multicast packet, the 429 slave can unicast the corresponding BT-LE packet to the master. The 430 master MUST provide a table for mapping different types of multicast 431 addresses (all-nodes, all-routers and solicited-node multicast 432 addresses) to the corresponding IIDs and Device Addresses. 434 3.3. Internet connectivity scenarios 436 In a typical scenario, the BT-LE network is connected to the 437 Internet. 439 h ____________ 440 \ / \ 441 h ---- 6LBR --- | Internet | 442 / \____________/ 443 h 444 h: host 445 <-- BT-LE --> 6LBR: 6LoWPAN Border Router 447 Figure 5: BT-LE network connected to the Internet 449 In some scenarios, the BT-LE network may transiently or permanently 450 be an isolated network. 452 h h h: host 453 \ / 6LBR: 6LoWPAN Border Router 454 h --- 6LBR -- h 455 / \ 456 h h 458 Figure 6: Isolated BT-LE network 460 Host-to-master and master-to-host communication MUST use the same 461 mechanisms as would be used in global IPv6 communications. The 462 gateway is used to route the packets to one of its slaves. 464 4. IANA Considerations 466 There are no IANA considerations related to this document. 468 5. Security Considerations 470 The transmission of IPv6 over BT-LE links has similar requirements 471 and concerns for security as for IEEE 802.15.4. IPv6 over BT-LE 472 SHOULD be protected by using BT-LE Link Layer security. 474 BT-LE Link Layer supports encryption and authentication by using the 475 Counter with CBC-MAC (CCM) mechanism [RFC3610] and a 128-bit AES 476 block cipher. Upper layer security mechanisms may exploit this 477 functionality when it is available. (Note: CCM does not consume 478 bytes from the maximum per-packet L2CAP data size, since the link 479 layer data unit has a specific field for them when they are used.) 481 Key management in BT-LE is provided by the Security Manager Protocol 482 (SMP), as defined in [BTCorev4.0]. 484 6. Additional contributors 486 Kanji Kerai, Jari Mutikainen, David Canfeng-Chen and Minjun Xi from 487 Nokia have contributed significantly to this document. 489 7. Acknowledgements 491 The Bluetooth, Bluetooth Smart and Bluetooth Smart Ready marks are 492 registred trademarks owned by Bluetooth SIG, Inc. 494 Samita Chakrabarti and Erik Nordmark have provided valuable feedback 495 for this draft. 497 8. References 499 8.1. Normative References 501 [BTCorev4.0] 502 "Bluetooth Core Specification v4.0, http:// 503 www.bluetooth.org/Technical/Specifications/adopted.htm". 505 [I-D.ietf-6lowpan-nd] 506 Shelby, Z., Chakrabarti, S., and E. Nordmark, "Neighbor 507 Discovery Optimization for Low Power and Lossy Networks 508 (6LoWPAN)", draft-ietf-6lowpan-nd-19 (work in progress), 509 July 2012. 511 [IEEE802-2001] 512 "IEEE 802-2001 standard, 513 http://standards.ieee.org/findstds/standard/ 514 802-2001.html". 516 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 517 Requirement Levels", BCP 14, RFC 2119, March 1997. 519 [RFC2464] Crawford, M., "Transmission of IPv6 Packets over Ethernet 520 Networks", RFC 2464, December 1998. 522 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 523 Architecture", RFC 4291, February 2006. 525 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 526 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 527 September 2007. 529 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 530 Address Autoconfiguration", RFC 4862, September 2007. 532 [RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler, 533 "Transmission of IPv6 Packets over IEEE 802.15.4 534 Networks", RFC 4944, September 2007. 536 [RFC6282] Hui, J. and P. Thubert, "Compression Format for IPv6 537 Datagrams over IEEE 802.15.4-Based Networks", RFC 6282, 538 September 2011. 540 8.2. Informative References 542 [RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic 543 Host Configuration Protocol (DHCP) version 6", RFC 3633, 544 December 2003. 546 [RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy 547 Extensions for Stateless Address Autoconfiguration in 548 IPv6", RFC 4941, September 2007. 550 Appendix A. Bluetooth Low Energy fragmentation and L2CAP Modes 552 This section provides an overview of Fragmentation and Recombination 553 (FAR) method and L2CAP modes in Bluetooth Low Energy. FAR is an 554 L2CAP mechanism, in which an L2CAP entity can take the (large) upper 555 layer PDU, prepend the L2CAP header (4 bytes in the Basic L2CAP mode) 556 and break the resulting L2CAP PDU into fragments which can then be 557 directly encapsulated into Data channel PDUs. There are bits in the 558 Data channel PDUs which identify whether the payload is a complete 559 L2CAP PDU or the first of a set of fragments, or one of the rest of 560 the fragments. 562 There are five L2CAP modes defined in the BT 4.0 spec. These modes 563 are: Retransmission Mode (a Go-Back-N mechanism is used), Enhanced 564 Retransmission Mode (includes selective NAK among others), Flow 565 Control Mode (PDUs are numbered, but there are no retransmissions), 566 Streaming Mode (PDUs are numbered, but there are no ACKs of any kind) 567 and Basic L2CAP Mode. 569 Authors' Addresses 571 Johanna Nieminen (editor) 572 Nokia 573 Itaemerenkatu 11-13 574 FI-00180 Helsinki 575 Finland 577 Email: johanna.1.nieminen@nokia.com 579 Basavaraj Patil 580 Nokia 581 6021 Connection drive 582 Irving, TX 75039 583 USA 585 Email: basavaraj.patil@nokia.com 587 Teemu Savolainen 588 Nokia 589 Hermiankatu 12 D 590 FI-33720 Tampere 591 Finland 593 Email: teemu.savolainen@nokia.com 595 Markus Isomaki 596 Nokia 597 Keilalahdentie 2-4 598 FI-02150 Espoo 599 Finland 601 Email: markus.isomaki@nokia.com 603 Zach Shelby 604 Sensinode 605 Hallituskatu 13-17D 606 FI-90100 Oulu 607 Finland 609 Email: zach.shelby@sensinode.com 610 Carles Gomez 611 Universitat Politecnica de Catalunya/i2CAT 612 C/Esteve Terradas, 7 613 Castelldefels 08860 614 Spain 616 Email: carlesgo@entel.upc.edu