< draft-ietf-6lo-btle-04.txt   draft-ietf-6lo-btle-05.txt >
6Lo Working Group J. Nieminen 6Lo Working Group J. Nieminen
Internet-Draft T. Savolainen Internet-Draft T. Savolainen
Intended status: Standards Track M. Isomaki Intended status: Standards Track M. Isomaki
Expires: June 19, 2015 Nokia Expires: July 12, 2015 Nokia
B. Patil B. Patil
AT&T AT&T
Z. Shelby Z. Shelby
Arm Arm
C. Gomez C. Gomez
Universitat Politecnica de Catalunya/i2CAT Universitat Politecnica de Catalunya/i2CAT
December 16, 2014 January 8, 2015
Transmission of IPv6 Packets over BLUETOOTH(R) Low Energy Transmission of IPv6 Packets over BLUETOOTH(R) Low Energy
draft-ietf-6lo-btle-04 draft-ietf-6lo-btle-05
Abstract Abstract
Bluetooth Smart is the brand name for the Bluetooth low energy Bluetooth Smart is the brand name for the Bluetooth low energy
feature in the Bluetooth specification defined by the Bluetooth feature in the Bluetooth specification defined by the Bluetooth
Special Interest Group. The standard Bluetooth radio has been widely Special Interest Group. The standard Bluetooth radio has been widely
implemented and available in mobile phones, notebook computers, audio implemented and available in mobile phones, notebook computers, audio
headsets and many other devices. The low power version of Bluetooth headsets and many other devices. The low power version of Bluetooth
is a specification that enables the use of this air interface with is a specification that enables the use of this air interface with
devices such as sensors, smart meters, appliances, etc. The low devices such as sensors, smart meters, appliances, etc. The low
skipping to change at page 1, line 47 skipping to change at page 1, line 47
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on June 19, 2015. This Internet-Draft will expire on July 12, 2015.
Copyright Notice Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the Copyright (c) 2015 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
skipping to change at page 2, line 45 skipping to change at page 2, line 45
3.2.3.1. Remote destination example . . . . . . . . . . . 11 3.2.3.1. Remote destination example . . . . . . . . . . . 11
3.2.4. Unicast and Multicast address mapping . . . . . . . . 12 3.2.4. Unicast and Multicast address mapping . . . . . . . . 12
3.3. Internet connectivity scenarios . . . . . . . . . . . . . 12 3.3. Internet connectivity scenarios . . . . . . . . . . . . . 12
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
5. Security Considerations . . . . . . . . . . . . . . . . . . . 13 5. Security Considerations . . . . . . . . . . . . . . . . . . . 13
6. Additional contributors . . . . . . . . . . . . . . . . . . . 14 6. Additional contributors . . . . . . . . . . . . . . . . . . . 14
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 14
8.1. Normative References . . . . . . . . . . . . . . . . . . 14 8.1. Normative References . . . . . . . . . . . . . . . . . . 14
8.2. Informative References . . . . . . . . . . . . . . . . . 15 8.2. Informative References . . . . . . . . . . . . . . . . . 15
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16
1. Introduction 1. Introduction
Bluetooth low energy (LE) is a radio technology targeted for devices Bluetooth low energy (LE) is a radio technology targeted for devices
that operate with coin cell batteries or minimalistic power sources, that operate with coin cell batteries or minimalistic power sources,
which means that low power consumption is essential. Bluetooth LE is which means that low power consumption is essential. Bluetooth LE is
an especially attractive technology for Internet of Things an especially attractive technology for Internet of Things
applications, such as health monitors, environmental sensing, applications, such as health monitors, environmental sensing,
proximity applications and many others. proximity applications and many others.
skipping to change at page 8, line 24 skipping to change at page 8, line 24
level, the link can be considered up and IPv6 address configuration level, the link can be considered up and IPv6 address configuration
and transmission can begin. and transmission can begin.
3.2.1. Stateless address autoconfiguration 3.2.1. Stateless address autoconfiguration
At network interface initialization, both 6LN and 6LBR SHALL generate At network interface initialization, both 6LN and 6LBR SHALL generate
and assign to the Bluetooth LE network interface IPv6 link-local and assign to the Bluetooth LE network interface IPv6 link-local
addresses [RFC4862] based on the 48-bit Bluetooth device addresses addresses [RFC4862] based on the 48-bit Bluetooth device addresses
(see Section 2.3) that were used for establishing underlying (see Section 2.3) that were used for establishing underlying
Bluetooth LE connection. A 64-bit Interface Identifier (IID) is Bluetooth LE connection. A 64-bit Interface Identifier (IID) is
formed from 48-bit device address as defined in RFC 2464 [RFC2464]. formed from 48-bit Bluetooth device address by inserting two octets,
with hexadecimal values of 0xFF and 0xFE in the middle of the 48-bit
Bluetooth device address as shown in Figure 4. In the Figure letter
'b' represents a bit from Bluetooth device address.
|0 1|1 3|3 4|4 6|
|0 5|6 1|2 7|8 3|
+----------------+----------------+----------------+----------------+
|bbbbbbbbbbbbbbbb|bbbbbbbb11111111|11111110bbbbbbbb|bbbbbbbbbbbbbbbb|
+----------------+----------------+----------------+----------------+
Figure 4: Formation of IID from Bluetooth device adddress
The IID is then appended with prefix fe80::/64, as described in RFC The IID is then appended with prefix fe80::/64, as described in RFC
4291 [RFC4291] and as depicted in Figure 4. The same link-local 4291 [RFC4291] and as depicted in Figure 5. The same link-local
address SHALL be used for the lifetime of the Bluetooth LE L2CAP address SHALL be used for the lifetime of the Bluetooth LE L2CAP
channel. (After Bluetooth LE logical link has been established, it channel. (After Bluetooth LE logical link has been established, it
is referenced with a Connection Handle in HCI. Thus possibly is referenced with a Connection Handle in HCI. Thus possibly
changing device addresses do not impact data flows within existing changing device addresses do not impact data flows within existing
L2CAP channel. Hence there is no need to change IPv6 link-local L2CAP channel. Hence there is no need to change IPv6 link-local
addresses even if devices change their random device addresses during addresses even if devices change their random device addresses during
L2CAP channel lifetime). L2CAP channel lifetime).
10 bits 54 bits 64 bits 10 bits 54 bits 64 bits
+----------+-----------------+----------------------+ +----------+-----------------+----------------------+
|1111111010| zeros | Interface Identifier | |1111111010| zeros | Interface Identifier |
+----------+-----------------+----------------------+ +----------+-----------------+----------------------+
Figure 4: IPv6 link-local address in Bluetooth LE Figure 5: IPv6 link-local address in Bluetooth LE
A 6LN MUST join the all-nodes multicast address. There is no need A 6LN MUST join the all-nodes multicast address. There is no need
for 6LN to join the solicited-node multicast address, since 6LBR will for 6LN to join the solicited-node multicast address, since 6LBR will
know device addresses and hence link-local addresses of all connected know device addresses and hence link-local addresses of all connected
6LNs. The 6LBR will ensure no two devices with the same Bluetooth LE 6LNs. The 6LBR will ensure no two devices with the same Bluetooth LE
device address are connected at the same time. Effectively duplicate device address are connected at the same time. Effectively duplicate
address detection for link-local addresses is performed by the 6LBR's address detection for link-local addresses is performed by the 6LBR's
software responsible of discovery of IP-enabled Bluetooth LE nodes software responsible of discovery of IP-enabled Bluetooth LE nodes
and of starting Bluetooth LE connection establishment procedures. and of starting Bluetooth LE connection establishment procedures.
This approach increases complexity of 6LBR, but reduces power This approach increases complexity of 6LBR, but reduces power
consumption on both 6LN and 6LBR at link establishment phase by consumption on both 6LN and 6LBR at link establishment phase by
reducing number of mandatory packet transmissions. reducing number of mandatory packet transmissions.
After link-local address configuration, 6LN sends Router Solicitation After link-local address configuration, 6LN sends Router Solicitation
messages as described in [RFC4861] Section 6.3.7. messages as described in [RFC4861] Section 6.3.7.
For non-link-local addresses a 64-bit IID MAY be formed by utilizing For non-link-local addresses a 64-bit IID MAY be formed by utilizing
the 48-bit Bluetooth device address. Alternatively, a randomly the 48-bit Bluetooth device address. Alternatively, a randomly
generated IID (see Section 3.2.2) can be used instead, for example, generated IID (see Section 3.2.2) can be used instead, for example,
skipping to change at page 9, line 44 skipping to change at page 10, line 11
'Neighbor Discovery Optimization for IPv6 over Low-Power Wireless 'Neighbor Discovery Optimization for IPv6 over Low-Power Wireless
Personal Area Networks (6LoWPANs)' [RFC6775] describes the neighbor Personal Area Networks (6LoWPANs)' [RFC6775] describes the neighbor
discovery approach as adapted for use in several 6LoWPAN topologies, discovery approach as adapted for use in several 6LoWPAN topologies,
including the mesh topology. Bluetooth LE does not support mesh including the mesh topology. Bluetooth LE does not support mesh
networks and hence only those aspects that apply to a star topology networks and hence only those aspects that apply to a star topology
are considered. are considered.
The following aspects of the Neighbor Discovery optimizations The following aspects of the Neighbor Discovery optimizations
[RFC6775] are applicable to Bluetooth LE 6LNs: [RFC6775] are applicable to Bluetooth LE 6LNs:
1. A Bluetooth LE 6LN MUST register its non-link-local addresses 1. A Bluetooth LE 6LN SHOULD NOT register its IID for link-local
with the 6LBR by sending a Neighbor Solicitation (NS) message with address. A Bluetooth LE 6LN MUST register its IIDs for non-link-
the Address Registration Option (ARO) and process the Neighbor local addresses with the 6LBR by sending a Neighbor Solicitation (NS)
Advertisement (NA) accordingly. The NS with the ARO option MUST be message with the Address Registration Option (ARO) and process the
sent irrespective of the method used to generate the IID. The 6LN Neighbor Advertisement (NA) accordingly. The NS with the ARO option
MUST register only one IPv6 address per IPv6 prefix available on a MUST be sent irrespective of the method used to generate the IID. If
link. the 6LN registers multiple IIDs per IPv6 prefix available on a link,
the 6LBR will not be able to fully elide IID on downlink packets
(6LBR has to send IID bits inline).
2. For sending Router Solicitations and processing Router 2. For sending Router Solicitations and processing Router
Advertisements the Bluetooth LE 6LNs MUST, respectively, follow Advertisements the Bluetooth LE 6LNs MUST, respectively, follow
Sections 5.3 and 5.4 of the [RFC6775]. Sections 5.3 and 5.4 of the [RFC6775].
3.2.3. Header compression 3.2.3. Header compression
Header compression as defined in RFC 6282 [RFC6282], which specifies Header compression as defined in RFC 6282 [RFC6282], which specifies
the compression format for IPv6 datagrams on top of IEEE 802.15.4, is the compression format for IPv6 datagrams on top of IEEE 802.15.4, is
REQUIRED in this document as the basis for IPv6 header compression on REQUIRED in this document as the basis for IPv6 header compression on
skipping to change at page 12, line 25 skipping to change at page 12, line 38
to or through 6LBR. Hence, when a 6LN needs to transmit an IPv6 to or through 6LBR. Hence, when a 6LN needs to transmit an IPv6
multicast packet, the 6LN will unicast the corresponding Bluetooth LE multicast packet, the 6LN will unicast the corresponding Bluetooth LE
packet to the 6LBR. The 6LBR will then forward the multicast packet packet to the 6LBR. The 6LBR will then forward the multicast packet
to other 6LNs. To avoid excess of unwanted multicast traffic being to other 6LNs. To avoid excess of unwanted multicast traffic being
sent to 6LNs, the 6LBR SHOULD implement MLD Snooping feature sent to 6LNs, the 6LBR SHOULD implement MLD Snooping feature
[RFC4541]. [RFC4541].
3.3. Internet connectivity scenarios 3.3. Internet connectivity scenarios
In a typical scenario, the Bluetooth LE network is connected to the In a typical scenario, the Bluetooth LE network is connected to the
Internet as shown in the Figure 5. Internet as shown in the Figure 6.
6LN 6LN
\ ____________ \ ____________
\ / \ \ / \
6LN ---- 6LBR ----- | Internet | 6LN ---- 6LBR ----- | Internet |
/ \____________/ / \____________/
/ /
6LN 6LN
<-- Bluetooth LE --> <-- Bluetooth LE -->
Figure 5: Bluetooth LE network connected to the Internet Figure 6: Bluetooth LE network connected to the Internet
In some scenarios, the Bluetooth LE network may transiently or In some scenarios, the Bluetooth LE network may transiently or
permanently be an isolated network as shown in the Figure 6. permanently be an isolated network as shown in the Figure 7.
6LN 6LN 6LN 6LN
\ / \ /
\ / \ /
6LN --- 6LBR --- 6LN 6LN --- 6LBR --- 6LN
/ \ / \
/ \ / \
6LN 6LN 6LN 6LN
<--- Bluetooth LE ---> <--- Bluetooth LE --->
Figure 6: Isolated Bluetooth LE network Figure 7: Isolated Bluetooth LE network
It is also possible to have point-to-point connection between two It is also possible to have point-to-point connection between two
6LNs, one of which being central and another being peripheral. 6LNs, one of which being central and another being peripheral.
Similarly, it is possible to have point-to-point connections between Similarly, it is possible to have point-to-point connections between
two 6LBRs, one of which being central and another being peripheral. two 6LBRs, one of which being central and another being peripheral.
At this point in time mesh networking with Bluetooth LE is not At this point in time mesh networking with Bluetooth LE is not
specified. specified.
4. IANA Considerations 4. IANA Considerations
skipping to change at page 14, line 41 skipping to change at page 15, line 12
Bluetooth Special Interest Group, "Bluetooth Core Bluetooth Special Interest Group, "Bluetooth Core
Specification Version 4.1", December 2013. Specification Version 4.1", December 2013.
[IPSP] Bluetooth Special Interest Group, "Bluetooth Internet [IPSP] Bluetooth Special Interest Group, "Bluetooth Internet
Protocol Support Profile Specification Version 1.0.0", Protocol Support Profile Specification Version 1.0.0",
December 2014. December 2014.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2464] Crawford, M., "Transmission of IPv6 Packets over Ethernet
Networks", RFC 2464, December 1998.
[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing
Architecture", RFC 4291, February 2006. Architecture", RFC 4291, February 2006.
[RFC4541] Christensen, M., Kimball, K., and F. Solensky, [RFC4541] Christensen, M., Kimball, K., and F. Solensky,
"Considerations for Internet Group Management Protocol "Considerations for Internet Group Management Protocol
(IGMP) and Multicast Listener Discovery (MLD) Snooping (IGMP) and Multicast Listener Discovery (MLD) Snooping
Switches", RFC 4541, May 2006. Switches", RFC 4541, May 2006.
[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
"Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,
 End of changes. 16 change blocks. 
24 lines changed or deleted 34 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/