idnits 2.17.1 draft-ietf-6lowpan-btle-10.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 (September 17, 2012) is 4236 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 386, but not defined == Missing Reference: 'RFC 4941' is mentioned on line 341, but not defined ** Obsolete undefined reference: RFC 4941 (Obsoleted by RFC 8981) -- 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 (~~), 3 warnings (==), 4 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: March 21, 2013 Nokia 6 B. Patil 8 Z. Shelby 9 Sensinode 10 C. Gomez 11 Universitat Politecnica de 12 Catalunya/i2CAT 13 September 17, 2012 15 Transmission of IPv6 Packets over Bluetooth Low Energy 16 draft-ietf-6lowpan-btle-10 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 and enables 25 the use of this air interface with devices such as sensors, smart 26 meters, appliances, etc. The low power variant of Bluetooth is 27 currently specified in revision 4.0 of the Bluetooth specifications 28 (Bluetooth 4.0). This document describes how IPv6 is transported 29 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 March 21, 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 2. Bluetooth Low Energy . . . . . . . . . . . . . . . . . . . . . 3 66 2.1. Bluetooth Low Energy stack . . . . . . . . . . . . . . . . 4 67 2.2. Link layer roles and topology . . . . . . . . . . . . . . 4 68 2.3. BT-LE device addressing . . . . . . . . . . . . . . . . . 5 69 2.4. BT-LE packets sizes and MTU . . . . . . . . . . . . . . . 5 70 3. Specification of IPv6 over Bluetooth Low Energy . . . . . . . 6 71 3.1. Protocol stack . . . . . . . . . . . . . . . . . . . . . . 6 72 3.2. Link model . . . . . . . . . . . . . . . . . . . . . . . . 7 73 3.2.1. Stateless address autoconfiguration . . . . . . . . . 8 74 3.2.2. Neighbor discovery . . . . . . . . . . . . . . . . . . 8 75 3.2.3. Header compression . . . . . . . . . . . . . . . . . . 9 76 3.2.4. Unicast and Multicast address mapping . . . . . . . . 10 77 3.3. Internet connectivity scenarios . . . . . . . . . . . . . 10 78 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 79 5. Security Considerations . . . . . . . . . . . . . . . . . . . 11 80 6. Additional contributors . . . . . . . . . . . . . . . . . . . 12 81 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12 82 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 83 8.1. Normative References . . . . . . . . . . . . . . . . . . . 12 84 8.2. Informative References . . . . . . . . . . . . . . . . . . 13 85 Appendix A. Bluetooth Low Energy fragmentation and L2CAP Modes . 13 86 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14 88 1. Introduction 90 Bluetooth Low Energy (BT-LE) is a radio technology targeted for 91 devices that operate with coin cell batteries or minimalistic power 92 sources, which means that low power consumption is essential. BT-LE 93 is an especially attractive technology for Internet of Things 94 applications, such as health monitors, environmental sensing, 95 proximity applications and many others. 97 Considering the potential for the exponential growth in the number of 98 sensors and Internet connected devices and things, IPv6 is an ideal 99 protocol due to the large address space it provides. In addition, 100 IPv6 provides tools for stateless address autoconfiguration, which is 101 particularly suitable for sensor network applications and nodes which 102 have very limited processing power or lack a full-fledged operating 103 system. 105 [RFC4944] specifies the transmission of IPv6 over IEEE 802.15.4. The 106 Bluetooth Low Energy link in many respects has similar 107 characteristics to that of IEEE 802.15.4. Many of the mechanisms 108 defined in [RFC4944] can be applied to the transmission of IPv6 on 109 Bluetooth Low Energy links. This document specifies the details of 110 IPv6 transmission over Bluetooth Low Energy links. 112 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 113 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 114 document are to be interpreted as described in RFC 2119 [RFC2119]. 116 The terms 6LN, 6LR and 6LBR are defined as in [I-D.ietf-6lowpan-nd]. 118 2. Bluetooth Low Energy 120 BT-LE is designed for transferring small amounts of data infrequently 121 at modest data rates at a very low cost per bit. Bluetooth Special 122 Interest Group has introduced two trademarks, Bluetooth Smart for 123 single-mode devices (a device that only supports BT-LE) and Bluetooth 124 Smart Ready for dual-mode devices. In the rest of the draft, the 125 term BT-LE refers to both types of devices. 127 BT-LE is an integral part of the BT 4.0 specification [BTCorev4.0]. 128 Devices such as mobile phones, notebooks, tablets and other handheld 129 computing devices which include BT 4.0 chipsets also have the low- 130 energy functionality of Bluetooth. BT-LE is also included in many 131 different types of accessories that collaborate with mobile devices 132 such as phones, tablets and notebook computers. An example of a use 133 case for a BT-LE accessory is a heart rate monitor that sends data 134 via the mobile phone to a server on the Internet. 136 2.1. Bluetooth Low Energy stack 138 The lower layer of the BT-LE stack consists of the Physical (PHY) and 139 the Link Layer (LL). The Physical Layer transmits and receives the 140 actual packets. The Link Layer is responsible for providing medium 141 access, connection establishment, error control and flow control. 142 The upper layer consists of the Logical Link Control and Adaptation 143 Protocol (L2CAP), Generic Attribute protocol (GATT) and Generic 144 Access Profile (GAP) as shown in Figure 1. GATT and BT-LE profiles 145 together enable the creation of applications in a standardized way 146 without using IP. L2CAP provides multiplexing capability by 147 multiplexing the data channels from the above layers. L2CAP also 148 provides fragmentation and reassembly for large data packets. 150 +----------------------------------------+------------------+ 151 | Applications | 152 +----------------------------------------+------------------+ 153 | Generic Attribute Profile | Generic Access | 154 +----------------------------------------+ Profile | 155 | Attribute Protocol |Security Manager | | 156 +--------------------+-------------------+------------------+ 157 | Logical Link Control and Adaptation | 158 +--------------------+-------------------+------------------+ 159 | Host Controller Interface | 160 +--------------------+-------------------+------------------+ 161 | Link Layer | Direct Test Mode | 162 +--------------------+-------------------+------------------+ 163 | Physical Layer | 164 +--------------------+-------------------+------------------+ 166 Figure 1: BT-LE Protocol Stack 168 2.2. Link layer roles and topology 170 BT-LE defines two Link Layer roles: the Master Role and the Slave 171 Role. A device in the Master Role, which is called master, can 172 manage multiple simultaneous connections with a number of devices in 173 the Slave Role, called slaves. A slave can only be connected to a 174 single master. Hence, a BT-LE network (i.e. a BT-LE piconet) follows 175 a star topology shown in the Figure 2. This specification primarily 176 addresses the situation where the BT-LE Slave is a host but not a 177 router at the IP level. 179 [BTLE-Slave]-----\ /-----[BTLE-Slave] 180 \ / 181 [BTLE-Slave]-----/[BTLE-Master]/-----[BTLE-Slave] 182 / \ 183 [BTLE-Slave]-----/ \-----[BTLE-Slave] 185 Figure 2: BT-LE Star Topology 187 A master is assumed to be less constrained than a slave. Hence, 188 master and slave can act as 6LoWPAN Border Router (6LBR) and host, 189 respectively. 191 In BT-LE, communication only takes place between a master and a 192 slave. Hence, in a BT-LE network using IP, a radio hop is equivalent 193 to an IP link and vice versa. 195 2.3. BT-LE device addressing 197 Every BT-LE device is identified by a unique 48 bit Bluetooth Device 198 Address (BD_ADDR). A Bluetooth Smart device such as a sensor can use 199 a public or a random device address (generated internally). The 200 public address is created according to the IEEE 802-2001 standard 201 [IEEE802-2001] and using a valid Organizationally Unique Identifier 202 (OUI) obtained from the IEEE Registration Authority. 204 2.4. BT-LE packets sizes and MTU 206 Maximum size of the payload in the BT-LE data channel PDU is 27 207 bytes. Depending on the L2CAP mode in use, the amount of data 208 available for transporting IP bytes in the single BT-LE data channel 209 PDU ranges between 19 and 27 octets. For power efficient 210 communication between two BT-LE devices, data and its header should 211 fit in a single BT-LE data channel PDU. However, IPv6 requires 212 support for an MTU of 1280 bytes. An inherent function of the BT-LE 213 L2CAP layer, called Fragmentation and Recombination (FAR), can assist 214 in transferring IPv6 packets that do not fit in a single BT-LE data 215 channel PDU. 217 The maximum IP datagram size that can be transported by L2CAP depends 218 on the L2CAP mode. The Basic L2CAP Mode allows a maximum payload 219 size (i.e. IP datagram size) of 65535 bytes per L2CAP PDU. The rest 220 of the L2CAP modes allow a maximum payload size that ranges between 221 65527 and 65533 bytes per L2CAP PDU. Appendix A describes FAR 222 operation and five L2CAP Modes. 224 3. Specification of IPv6 over Bluetooth Low Energy 226 BT-LE technology sets strict requirements for low power consumption 227 and thus limits the allowed protocol overhead. 6LoWPAN standards 228 [RFC4944], [I-D.ietf-6lowpan-nd] and [RFC6282] provide useful generic 229 functionality like header compression [Section 3.2.3], link-local 230 IPv6 addresses, Neighbor Discovery [Section 3.2.2] and stateless IP- 231 address autoconfiguration [Section 3.2.1] for reducing the overhead 232 in 802.15.4 networks. This functionality can be partly applied to 233 BT-LE. 235 A significant difference between IEEE 802.15.4 and BT-LE is that the 236 former supports both star and mesh topology (and requires a routing 237 protocol), whereas BT-LE does not currently support the formation of 238 multihop networks at the link layer. In consequence, the mesh header 239 defined in [RFC4944] for mesh under routing MUST NOT be used in BT-LE 240 networks. In addition, a BT-LE device MUST NOT play the role of a 241 6LoWPAN Router (6LR). 243 3.1. Protocol stack 245 In order to enable transmission of IPv6 packets over BT-LE, a new 246 fixed L2CAP channel ID is being reserved for IPv6 traffic by the BT- 247 SIG. A request for allocation of a new fixed channel ID for IPv6 248 traffic by the BT-SIG should be submitted through the liaison process 249 or formal communique from the 6lowpan chairs and respective area 250 directors. Until a channel ID is allocated by BT-SIG, the channel ID 251 0x0007 is recommended for experimentation. Once the channel ID is 252 allocated, the allocated value MUST be used. Figure 3 illustrates 253 IPv6 over BT-LE stack. UDP/TCP are provided as examples of a 254 transport protocol, but the stack can be used by other transport 255 protocols as well. 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 specification 286 requires that FAR functionality MUST be provided in the L2CAP layer 287 up to the IPv6 minimum MTU of 1280 bytes. The corresponding L2CAP 288 Mode MUST be Basic Mode. Since FAR in BT-LE is a function of the 289 L2CAP layer, fragmentation functionality as defined in [RFC4944] MUST 290 NOT be used in BT-LE networks. This specification also assumes the 291 IPv6 header compression format specified in [RFC 6282]. It is also 292 assumed that the IPv6 payload length can be inferred from the L2CAP 293 header length and also assumes that IPv6 addresses assigned to 294 6LoWPAN interfaces are formed with an IID derived directly from the 295 48-bit Bluetooth device addresses, as described in subsection 3.2.1. 297 The BT-LE link between two communicating nodes can be considered to 298 be a point-to-point or point-to-multipoint link. When one of the 299 communicating nodes is in the role of a master, then the link can be 300 viewed as a point-to-multipoint link. 302 When a host connects to another BT-LE device the link is up and IP 303 address configuration and transmission can occur. 305 3.2.1. Stateless address autoconfiguration 307 A BT-LE 6LN performs stateless address autoconfiguration as per 308 [RFC4862]. This specification mandates that the 64 bit Interface 309 Identifier (IID) for a BT-LE interface MUST be formed using a 310 Bluetooth Device Address that is a 48-bit unique public Bluetooth 311 address, [Section 2.3] as per the "IPv6 over Ethernet" specification 312 [RFC2464]. A BT-LE 6LN node MAY use this EUI-64 based IID or a 313 randomly generated IID [Section 3.2.2] for stateless address 314 autoconfiguration. Since the 48-bit public Bluetooth address is 315 globally unique, the "Universal/Local" (U/L) bit MUST be set to 0. 317 As defined in [RFC4291], the IPv6 link-local address for a BT-LE node 318 is formed by appending the IID, to the prefix FE80::/64, as depicted 319 in Figure 4. 321 The tool for a gateway to obtain an IPv6 prefix for numbering the 322 BT-LE network is out of scope of this document, but can for example 323 be accomplished via DHCPv6 Prefix Delegation [RFC3633]. The used 324 IPv6 prefix may change due to the gateway's movement. 326 3.2.2. Neighbor discovery 328 [I-D.ietf-6lowpan-nd] describes the neighbor discovery approach as 329 adapted for use in several 6LoWPAN topologies, including the mesh 330 topology. BT-LE does not support mesh networks and hence only those 331 aspects of the [I-D.ietf-6lowpan-nd] that apply to a star topology 332 are considered. 334 The following aspects of 6lowpan-nd are applicable to BT-LE 6LNS: 336 1. A BT-LE 6LN MUST register its address with the router by sending 337 a NS message with the ARO option and process the NA accordingly. The 338 NS with the ARO option SHOULD be sent irrespective of whether the IID 339 is derived from the unique 48 bit BT-LE device address or the IID is 340 a random value that is generated as per the privacy extensions for 341 stateless address autoconfiguration [RFC4941]. Although [RFC 4941] 342 permits the use of deprecated addresses for old connections, in this 343 specification we mandate that one interface MUST NOT use more than 344 one IID at any one time. 346 2. Sending a Router solicitation (RS) and processing Router 347 advertisements by BT-LE 6LNs MUST follow Sections 5.3 and 5.4 348 respectively of [I-D.ietf-6lowpan-nd]. 350 10 bits 54 bits 64 bits 351 +----------+-----------------+----------------------+ 352 |1111111010| zeros | Interface Identifier | 353 +----------+-----------------+----------------------+ 355 Figure 4: IPv6 link-local address in BT-LE 357 3.2.3. Header compression 359 Header compression, as defined in [RFC6282], which specifies the 360 compression format for IPv6 datagrams on top of IEEE 802.15.4 is 361 REQUIRED in this document as the basis for IPv6 header compression on 362 top of BT-LE. All headers MUST be compressed according to RFC 6282 363 encoding formats. In BT-LE the star topology structure can be 364 exploited in order to provide a mechanism for IID compression. The 365 following text describes the principles of IPv6 address compression 366 on top of BT-LE. 368 In a link-local communication, both the IPv6 source and destination 369 addresses MUST be elided [RFC6282], since the device knows that the 370 packet is destined for it even if the packet does not have 371 destination IPv6 address. On the other hand, a node SHALL learn the 372 IID of the other endpoint of each L2CAP connection it participates 373 in. By exploiting this information, a node that receives a data 374 channel PDU containing an IPv6 packet (or a part of it) can infer the 375 corresponding IPv6 source address. The device MUST maintain a 376 Neighbor Cache, in which the entries include both the IID of the 377 neighbor and the Device Address that identifies the neighbor. For 378 the type of communication considered in this paragraph, the following 379 settings MUST be used in the IPv6 compressed header: CID=0, SAC=0, 380 SAM=11, DAC=0, DAM=11. 382 When a BT-LE slave transmits an IPv6 packet to a remote destination 383 using global Unicast IPv6 addresses, if a context is defined for the 384 prefix of the slave global IPv6 address, the slave MUST indicate this 385 context in the corresponding source fields of the compressed IPv6 386 header as per Section 3.1 of [RFC 6282], and MUST elide the IPv6 387 source address. For this, the slave MUST use the following settings 388 in the IPv6 compressed header: CID=1, SAC=1, SAM=11. In this case, 389 the 6LBR/master can infer the elided IPv6 source address since 1) the 390 master/6LBR has previously assigned the prefix to the slaves; and 2) 391 the master/6LBR maintains a Neighbor Cache that relates the Device 392 Address and the IID of the corresponding slave. If a context is 393 defined for the IPv6 destination address, the slave MUST also 394 indicate this context in the corresponding destination fields of the 395 compressed IPv6 header, and MUST elide the prefix of the destination 396 IPv6 address. For this, the slave MUST set the DAM field of the 397 compressed IPv6 header as DAM=01 (if the context covers a 64-bit 398 prefix) or as DAM=11 (if the context covers a full, 128-bit address). 399 CID and DAC MUST be set to CID=1 and DAC=1. Note that when a context 400 is defined for the IPv6 destination address, the 6LBR/master can 401 infer the elided destination prefix by using the context. 403 When a master/6LBR receives an IPv6 packet sent by a remote node 404 outside the BT-LE network, and the destination of the packet is a 405 slave, if a context is defined for the prefix of the slave global 406 IPv6 address, the master/6LBR MUST indicate this context in the 407 corresponding destination fields of the compressed IPv6 header, and 408 MUST elide the IPv6 destination address of the packet before 409 forwarding it to the slave. For this, the master/6LBR MUST set the 410 DAM field of the IPv6 compressed header as DAM=11. CID and DAC MUST 411 be set to CID=1 and DAC=1. If a context is defined for the prefix of 412 the IPv6 source address, the master/6LBR MUST indicate this context 413 in the source fields of the compressed IPv6 header, and MUST elide 414 that prefix as well. For this, the master/6LBR MUST set the SAM 415 field of the IPv6 compressed header as SAM=01 (if the context covers 416 a 64-bit prefix) or SAM=11 (if the context covers a full, 128-bit 417 address). CID and SAC MUST be set to CID=1 and SAC=1. 419 3.2.4. Unicast and Multicast address mapping 421 The BT-LE link layer does not support multicast. Hence traffic is 422 always unicast between two BT-LE devices. Even in the case where a 423 master is attached to multiple slave BT-LE devices, the master device 424 cannot do a multicast to all the connected slave devices. If the 425 master device needs to send a multicast packet to all its slave 426 devices, it has to replicate the packet and unicast it on each link. 427 However, this may not be energy-efficient and particular care must be 428 taken if the master is battery-powered. In the opposite direction, a 429 slave can only transmit data to a single destination (i.e. the 430 master). Hence, if a slave transmits an IPv6 multicast packet, the 431 slave can unicast the corresponding BT-LE packet to the master. The 432 master MUST provide a table for mapping different types of multicast 433 addresses (all-nodes, all-routers and solicited-node multicast 434 addresses) to the corresponding IIDs and Device Addresses. 436 3.3. Internet connectivity scenarios 438 In a typical scenario, the BT-LE network is connected to the Internet 439 as shown in the Figure 5. 441 h ____________ 442 \ / \ 443 h ---- 6LBR --- | Internet | 444 / \____________/ 445 h 446 h: host 447 <-- BT-LE --> 6LBR: 6LoWPAN Border Router 449 Figure 5: BT-LE network connected to the Internet 451 In some scenarios, the BT-LE network may transiently or permanently 452 be an isolated network as shown in the Figure 6. 454 h h h: host 455 \ / 6LBR: 6LoWPAN Border Router 456 h --- 6LBR -- h 457 / \ 458 h h 460 Figure 6: Isolated BT-LE network 462 Host-to-master and master-to-host communication MUST use the same 463 mechanisms as would be used in global IPv6 communications. The 464 gateway is used to route the packets to one of its slaves. 466 4. IANA Considerations 468 There are no IANA considerations related to this document. 470 5. Security Considerations 472 The transmission of IPv6 over BT-LE links has similar requirements 473 and concerns for security as for IEEE 802.15.4. IPv6 over BT-LE 474 SHOULD be protected by using BT-LE Link Layer security. 476 BT-LE Link Layer supports encryption and authentication by using the 477 Counter with CBC-MAC (CCM) mechanism [RFC3610] and a 128-bit AES 478 block cipher. Upper layer security mechanisms may exploit this 479 functionality when it is available. (Note: CCM does not consume 480 bytes from the maximum per-packet L2CAP data size, since the link 481 layer data unit has a specific field for them when they are used.) 483 Key management in BT-LE is provided by the Security Manager Protocol 484 (SMP), as defined in [BTCorev4.0]. 486 6. Additional contributors 488 Kanji Kerai, Jari Mutikainen, David Canfeng-Chen and Minjun Xi from 489 Nokia have contributed significantly to this document. 491 7. Acknowledgements 493 The Bluetooth, Bluetooth Smart and Bluetooth Smart Ready marks are 494 registred trademarks owned by Bluetooth SIG, Inc. 496 Samita Chakrabarti and Erik Nordmark have provided valuable feedback 497 for this draft. 499 8. References 501 8.1. Normative References 503 [BTCorev4.0] 504 BLUETOOTH Special Interest Group, "BLUETOOTH Specification 505 Version 4.0", June 2010. 507 [I-D.ietf-6lowpan-nd] 508 Shelby, Z., Chakrabarti, S., and E. Nordmark, "Neighbor 509 Discovery Optimization for Low Power and Lossy Networks 510 (6LoWPAN)", draft-ietf-6lowpan-nd-21 (work in progress), 511 August 2012. 513 [IEEE802-2001] 514 Institute of Electrical and Electronics Engineers (IEEE), 515 "IEEE 802-2001 Standard for Local and Metropolitan Area 516 Networks: Overview and Architecture", 2002. 518 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 519 Requirement Levels", BCP 14, RFC 2119, March 1997. 521 [RFC2464] Crawford, M., "Transmission of IPv6 Packets over Ethernet 522 Networks", RFC 2464, December 1998. 524 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 525 Architecture", RFC 4291, February 2006. 527 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 528 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 529 September 2007. 531 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 532 Address Autoconfiguration", RFC 4862, September 2007. 534 [RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler, 535 "Transmission of IPv6 Packets over IEEE 802.15.4 536 Networks", RFC 4944, September 2007. 538 [RFC6282] Hui, J. and P. Thubert, "Compression Format for IPv6 539 Datagrams over IEEE 802.15.4-Based Networks", RFC 6282, 540 September 2011. 542 8.2. Informative References 544 [RFC3610] Whiting, D., Housley, R., and N. Ferguson, "Counter with 545 CBC-MAC (CCM)", RFC 3610, September 2003. 547 [RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic 548 Host Configuration Protocol (DHCP) version 6", RFC 3633, 549 December 2003. 551 [RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy 552 Extensions for Stateless Address Autoconfiguration in 553 IPv6", RFC 4941, September 2007. 555 Appendix A. Bluetooth Low Energy fragmentation and L2CAP Modes 557 This section provides an overview of Fragmentation and Recombination 558 (FAR) method and L2CAP modes in Bluetooth Low Energy. FAR is an 559 L2CAP mechanism, in which an L2CAP entity can take the (large) upper 560 layer PDU, prepend the L2CAP header (4 bytes in the Basic L2CAP mode) 561 and break the resulting L2CAP PDU into fragments which can then be 562 directly encapsulated into Data channel PDUs. There are bits in the 563 Data channel PDUs which identify whether the payload is a complete 564 L2CAP PDU or the first of a set of fragments, or one of the rest of 565 the fragments. 567 There are five L2CAP modes defined in the BT 4.0 spec. These modes 568 are: Retransmission Mode (a Go-Back-N mechanism is used), Enhanced 569 Retransmission Mode (includes selective NAK among others), Flow 570 Control Mode (PDUs are numbered, but there are no retransmissions), 571 Streaming Mode (PDUs are numbered, but there are no ACKs of any kind) 572 and Basic L2CAP Mode. 574 Authors' Addresses 576 Johanna Nieminen (editor) 577 Nokia 578 Itaemerenkatu 11-13 579 FI-00180 Helsinki 580 Finland 582 Email: johannamaria.nieminen@gmail.com 584 Teemu Savolainen (editor) 585 Nokia 586 Hermiankatu 12 D 587 FI-33720 Tampere 588 Finland 590 Email: teemu.savolainen@nokia.com 592 Markus Isomaki 593 Nokia 594 Keilalahdentie 2-4 595 FI-02150 Espoo 596 Finland 598 Email: markus.isomaki@nokia.com 600 Basavaraj Patil 601 6021 Connection drive 602 Irving, TX 75039 603 USA 605 Email: bpatil@ovi.com 607 Zach Shelby 608 Sensinode 609 Hallituskatu 13-17D 610 FI-90100 Oulu 611 Finland 613 Email: zach.shelby@sensinode.com 614 Carles Gomez 615 Universitat Politecnica de Catalunya/i2CAT 616 C/Esteve Terradas, 7 617 Castelldefels 08860 618 Spain 620 Email: carlesgo@entel.upc.edu