< draft-ietf-6lo-btle-11.txt   draft-ietf-6lo-btle-12.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: October 29, 2015 Nokia Expires: November 16, 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
April 27, 2015 May 15, 2015
IPv6 over BLUETOOTH(R) Low Energy IPv6 over BLUETOOTH(R) Low Energy
draft-ietf-6lo-btle-11 draft-ietf-6lo-btle-12
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 October 29, 2015. This Internet-Draft will expire on November 16, 2015.
Copyright Notice Copyright Notice
Copyright (c) 2015 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
skipping to change at page 2, line 35 skipping to change at page 2, line 35
2.1. Bluetooth LE stack . . . . . . . . . . . . . . . . . . . 4 2.1. Bluetooth LE stack . . . . . . . . . . . . . . . . . . . 4
2.2. Link layer roles and topology . . . . . . . . . . . . . . 5 2.2. Link layer roles and topology . . . . . . . . . . . . . . 5
2.3. Bluetooth LE device addressing . . . . . . . . . . . . . 5 2.3. Bluetooth LE device addressing . . . . . . . . . . . . . 5
2.4. Bluetooth LE packets sizes and MTU . . . . . . . . . . . 5 2.4. Bluetooth LE packets sizes and MTU . . . . . . . . . . . 5
3. Specification of IPv6 over Bluetooth Low Energy . . . . . . . 6 3. Specification of IPv6 over Bluetooth Low Energy . . . . . . . 6
3.1. Protocol stack . . . . . . . . . . . . . . . . . . . . . 7 3.1. Protocol stack . . . . . . . . . . . . . . . . . . . . . 7
3.2. Link model . . . . . . . . . . . . . . . . . . . . . . . 7 3.2. Link model . . . . . . . . . . . . . . . . . . . . . . . 7
3.2.1. Stateless address autoconfiguration . . . . . . . . . 8 3.2.1. Stateless address autoconfiguration . . . . . . . . . 8
3.2.2. Neighbor discovery . . . . . . . . . . . . . . . . . 10 3.2.2. Neighbor discovery . . . . . . . . . . . . . . . . . 10
3.2.3. Header compression . . . . . . . . . . . . . . . . . 10 3.2.3. Header compression . . . . . . . . . . . . . . . . . 10
3.2.3.1. Remote destination example . . . . . . . . . . . 11 3.2.3.1. Remote destination example . . . . . . . . . . . 12
3.2.4. Unicast and Multicast address mapping . . . . . . . . 12 3.2.3.2. Example of registration of multiple-addresses . . 13
3.2.4. Unicast and Multicast address mapping . . . . . . . . 13
3.3. Subnets and Internet connectivity scenarios . . . . . . . 13 3.3. Subnets and Internet connectivity scenarios . . . . . . . 13
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
5. Security Considerations . . . . . . . . . . . . . . . . . . . 14 5. Security Considerations . . . . . . . . . . . . . . . . . . . 15
6. Additional contributors . . . . . . . . . . . . . . . . . . . 14 6. Additional contributors . . . . . . . . . . . . . . . . . . . 15
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 15 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 15
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 16
8.1. Normative References . . . . . . . . . . . . . . . . . . 15 8.1. Normative References . . . . . . . . . . . . . . . . . . 16
8.2. Informative References . . . . . . . . . . . . . . . . . 16 8.2. Informative References . . . . . . . . . . . . . . . . . 16
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17
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
especially attractive technology for Internet of Things applications, especially attractive technology for Internet of Things applications,
such as health monitors, environmental sensing, proximity such as health monitors, environmental sensing, proximity
skipping to change at page 10, line 37 skipping to change at page 10, line 37
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 NOT register its link-local address. A 1. A Bluetooth LE 6LN MUST NOT register its link-local address. A
Bluetooth LE 6LN MUST register its non-link-local addresses with the Bluetooth LE 6LN MUST register its non-link-local addresses with the
6LBR by sending a Neighbor Solicitation (NS) message with the Address 6LBR by sending a Neighbor Solicitation (NS) message with the Address
Registration Option (ARO) and process the Neighbor Advertisement (NA) Registration Option (ARO) and process the Neighbor Advertisement (NA)
accordingly. The NS with the ARO option MUST be sent irrespective of accordingly. The NS with the ARO option MUST be sent irrespective of
the method used to generate the IID. If the 6LN registers for a same the method used to generate the IID. If the 6LN registers for a same
compression context multiple addresses that are not based on compression context multiple addresses that are not based on
Bluetooth device address, the 6LN and 6LBR will be unable to compress Bluetooth device address, the header compression efficiency will
IIDs and hence have to send IID bits inline. decrease (see Section 3.2.3).
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 11, line 21 skipping to change at page 11, line 21
case of Bluetooth LE, the field SHALL be filled with the 48-bit case of Bluetooth LE, the field SHALL be filled with the 48-bit
device address used by the Bluetooth LE node converted into 64-bit device address used by the Bluetooth LE node converted into 64-bit
Modified EUI-64 format [RFC4291]. Modified EUI-64 format [RFC4291].
To enable efficient header compression, the 6LBR MUST include 6LoWPAN To enable efficient header compression, the 6LBR MUST include 6LoWPAN
Context Option (6CO) [RFC6775] for all prefixes the 6LBR advertises Context Option (6CO) [RFC6775] for all prefixes the 6LBR advertises
in Router Advertisements for use in stateless address in Router Advertisements for use in stateless address
autoconfiguration. autoconfiguration.
When a 6LN is sending a packet to or through a 6LBR, it MUST fully When a 6LN is sending a packet to or through a 6LBR, it MUST fully
elide the source address if it is a link-local address or a non-link- elide the source address if it is a link-local address. A non-link-
local address 6LN has registered with ARO to the 6LBR for the local source address 6LN has registered with ARO to the 6LBR for the
indicated prefix. That is, if SAC=0 and SAM=11 the 6LN MUST be using indicated prefix MUST be fully elided if the source address is the
the link-local IPv6 address derived from Bluetooth LE device address, latest address 6LN has registered for the indicated prefix. If a
and if SAC=1 and SAM=11 the 6LN MUST have registered the source IPv6 source non-link-local address is not the latest registered, then the
address with the prefix related to compression context identified 64-bits of the IID SHALL be fully carried in-line (SAC=01) or if the
with Context Identifier Extension. The destination IPv6 address MUST first 48-bits of the IID match with the latest registered address,
be fully elided if the destination address is the same address to then the last 16-bits of the IID SHALL be carried in-line (SAC=10).
which the 6LN has succesfully registered its source IPv6 address with That is, if SAC=0 and SAM=11 the 6LN MUST be using the link-local
ARO (set DAC=0, DAM=11). The destination IPv6 address MUST be fully IPv6 address derived from Bluetooth LE device address, and if SAC=1
or partially elided if context has been set up for the destination and SAM=11 the 6LN MUST have registered the source IPv6 address with
address. For example, DAC=0 and DAM=01 when destination prefix is the prefix related to compression context and the 6LN MUST be
link-local, and DAC=1 and DAM=01 with Context Identifier Extension if referring to the latest registered address related to compression
context. The IPv6 address MUST be considered to be registered only
after the 6LBR has sent Neighbor Advertisement with ARO having status
field set to success. The destination IPv6 address MUST be fully
elided if the destination address is 6LBR's link-local-address based
on the 6LBR's Bluetooth device address (DAC=0, DAM=11). The
destination IPv6 address MUST be fully or partially elided if context
has been set up for the destination address. For example, DAC=0 and
DAM=01 when destination prefix is link-local, and DAC=1 and DAM=01 if
compression context has been configured for the used destination compression context has been configured for the used destination
prefix. prefix.
When a 6LBR is transmitting packets to 6LN, it MUST fully elide the When a 6LBR is transmitting packets to 6LN, it MUST fully elide the
source IID if the source IPv6 address is the one 6LN has used to source IID if the source IPv6 address is the link-local address based
register its address with ARO (set SAC=0, SAM=11), and it MUST elide on 6LBR's Bluetooth device address (SAC=0, SAM=11), and it MUST elide
the source prefix or address if a compression context related to the the source prefix or address if a compression context related to the
IPv6 source address has been set up. The 6LBR also MUST elide the IPv6 source address has been set up. The 6LBR also MUST fully elide
destination IPv6 address registered by the 6LN with ARO and thus 6LN the destination IPv6 address if it is the link-local-address based on
can determine it based on indication of link-local prefix (DAC=0) or 6LN's Bluetooth device address (DAC=0, DAM=11), or if the destination
indication of other prefix (DAC=1 with Context Identifier Extension). address is the latest registered by the 6LN with ARO for the
indicated context (DAC=1, DAM=11). If the destination address is a
non-link-local address and not the latest registered, then 6LN MUST
either include the IID part fully in-line (DAM=01) or, if the first
48-bits of IID match to the latest registered address, then elide
those 48-bits (DAM=10).
3.2.3.1. Remote destination example 3.2.3.1. Remote destination example
When a 6LN transmits an IPv6 packet to a remote destination using When a 6LN transmits an IPv6 packet to a remote destination using
global Unicast IPv6 addresses, if a context is defined for the 6LN's global Unicast IPv6 addresses, if a context is defined for the 6LN's
global IPv6 address, the 6LN has to indicate this context in the global IPv6 address, the 6LN has to indicate this context in the
corresponding source fields of the compressed IPv6 header as per corresponding source fields of the compressed IPv6 header as per
Section 3.1 of RFC 6282 [RFC6282], and has to elide the full IPv6 Section 3.1 of RFC 6282 [RFC6282], and has to elide the full IPv6
source address previously registered with ARO. For this, the 6LN source address previously registered with ARO (if using the latest
MUST use the following settings in the IPv6 compressed header: CID=1, registered address, otherwise full or part of IID may have to be
SAC=1, SAM=11. In this case, the 6LBR can infer the elided IPv6 transmitted in-line). For this, the 6LN MUST use the following
source address since 1) the 6LBR has previously assigned the prefix settings in the IPv6 compressed header: SAC=1 and SAM=11. The CID
to the 6LNs; and 2) the 6LBR maintains a Neighbor Cache that relates may be set 0 or 1, depending which context is used. In this case,
the Device Address and the IID the device has registered with ARO. the 6LBR can infer the elided IPv6 source address since 1) the 6LBR
If a context is defined for the IPv6 destination address, the 6LN has has previously assigned the prefix to the 6LNs; and 2) the 6LBR
to also indicate this context in the corresponding destination fields maintains a Neighbor Cache that relates the Device Address and the
of the compressed IPv6 header, and elide the prefix of or the full IID the device has registered with ARO. If a context is defined for
destination IPv6 address. For this, the 6LN MUST set the DAM field the IPv6 destination address, the 6LN has to also indicate this
of the compressed IPv6 header as DAM=01 (if the context covers a context in the corresponding destination fields of the compressed
64-bit prefix) or as DAM=11 (if the context covers a full, 128-bit IPv6 header, and elide the prefix of or the full destination IPv6
address). CID and DAC MUST be set to CID=1 and DAC=1. Note that address. For this, the 6LN MUST set the DAM field of the compressed
when a context is defined for the IPv6 destination address, the 6LBR IPv6 header as DAM=01 (if the context covers a 64-bit prefix) or as
can infer the elided destination prefix by using the context. DAM=11 (if the context covers a full, 128-bit address). DAC MUST be
set to 1. Note that when a context is defined for the IPv6
destination address, the 6LBR can infer the elided destination prefix
by using the context.
When a 6LBR receives an IPv6 packet sent by a remote node outside the When a 6LBR receives an IPv6 packet sent by a remote node outside the
Bluetooth LE network, and the destination of the packet is a 6LN, if Bluetooth LE network, and the destination of the packet is a 6LN, if
a context is defined for the prefix of the 6LN's global IPv6 address, a context is defined for the prefix of the 6LN's global IPv6 address,
the 6LBR has to indicate this context in the corresponding the 6LBR has to indicate this context in the corresponding
destination fields of the compressed IPv6 header. The 6LBR has to destination fields of the compressed IPv6 header. The 6LBR has to
elide the IPv6 destination address of the packet before forwarding elide the IPv6 destination address of the packet before forwarding
it, if the IPv6 destination address is inferable by the 6LN. For it, if the IPv6 destination address is inferable by the 6LN. For
this, the 6LBR will set the DAM field of the IPv6 compressed header this, the 6LBR will set the DAM field of the IPv6 compressed header
as DAM=11. CID and DAC needs to be set to CID=1 and DAC=1. If a as DAM=11 (if the address is the latest 6LN has registered). DAC
context is defined for the IPv6 source address, the 6LBR needs to needs to be set to 1. If a context is defined for the IPv6 source
indicate this context in the source fields of the compressed IPv6 address, the 6LBR needs to indicate this context in the source fields
header, and elide that prefix as well. For this, the 6LBR needs to of the compressed IPv6 header, and elide that prefix as well. For
set the SAM field of the IPv6 compressed header as SAM=01 (if the this, the 6LBR needs to set the SAM field of the IPv6 compressed
context covers a 64-bit prefix) or SAM=11 (if the context covers a header as SAM=01 (if the context covers a 64-bit prefix) or SAM=11
full, 128-bit address). CID and SAC are to be set to CID=1 and (if the context covers a full, 128-bit address). SAC is to be set to
SAC=1. 1.
3.2.3.2. Example of registration of multiple-addresses
As described above, a 6LN can register multiple non-link-local
addresses that map to a same compression context. From the multiple
address registered, only the latest address can be fully elided
(SAM=11, DAM=11), and the IIDs of previously registered addresses
have to be transmitted fully in-line (SAM=01, DAM=01) or in the best
case can be partially elided (SAM=10, DAM=10). This is illustred in
an example below.
1) A 6LN registers first address 2001:db8::1111:2222:3333:4444 to a
6LBR. At this point the address can be fully elided using SAC=1/
SAM=11 or DAC=1/DAM=11.
2) The 6LN registers second address 2001:db8::1111:2222:3333:5555 to
the 6LBR. As the second address is now the latest registered, it can
be fully elided using SAC=1/SAM=11 or DAC=1/DAM=11. The first
address can now be partially elided using SAC=1/SAM=10 or DAC=1/
DAM=10, as the first 112 bits of the address are the same between the
first and the second registered addresses.
3) Expiration of registration time for the first or the second
address has no impact on the compression. Hence even if secondly
registered address expires, the first address can only be partially
elided (SAC=1/SAM=10, DAC=1/DAM=10). The 6LN can register a new
address, or re-register an expired address, to become able to again
fully elide an address.
3.2.4. Unicast and Multicast address mapping 3.2.4. Unicast and Multicast address mapping
The Bluetooth LE link layer does not support multicast. Hence The Bluetooth LE link layer does not support multicast. Hence
traffic is always unicast between two Bluetooth LE nodes. Even in traffic is always unicast between two Bluetooth LE nodes. Even in
the case where a 6LBR is attached to multiple 6LNs, the 6LBR cannot the case where a 6LBR is attached to multiple 6LNs, the 6LBR cannot
do a multicast to all the connected 6LNs. If the 6LBR needs to send do a multicast to all the connected 6LNs. If the 6LBR needs to send
a multicast packet to all its 6LNs, it has to replicate the packet a multicast packet to all its 6LNs, it has to replicate the packet
and unicast it on each link. However, this may not be energy- and unicast it on each link. However, this may not be energy-
efficient and particular care must be taken if the master is battery- efficient and particular care must be taken if the master is battery-
skipping to change at page 15, line 11 skipping to change at page 15, line 51
Kanji Kerai, Jari Mutikainen, David Canfeng-Chen and Minjun Xi from Kanji Kerai, Jari Mutikainen, David Canfeng-Chen and Minjun Xi from
Nokia have contributed significantly to this document. Nokia have contributed significantly to this document.
7. Acknowledgements 7. Acknowledgements
The Bluetooth, Bluetooth Smart and Bluetooth Smart Ready marks are The Bluetooth, Bluetooth Smart and Bluetooth Smart Ready marks are
registred trademarks owned by Bluetooth SIG, Inc. registred trademarks owned by Bluetooth SIG, Inc.
Samita Chakrabarti, Brian Haberman, Marcel De Kogel, Jouni Korhonen, Samita Chakrabarti, Brian Haberman, Marcel De Kogel, Jouni Korhonen,
Erik Nordmark, Dave Thaler, Pascal Thubert, and Victor Zhodzishsky Erik Nordmark, Erik Rivard, Dave Thaler, Pascal Thubert, and Victor
have provided valuable feedback for this draft. Zhodzishsky have provided valuable feedback for this draft.
Authors would like to give special acknowledgements for Krishna Authors would like to give special acknowledgements for Krishna
Shingala, Frank Berntsen, and Bluetooth SIG's Internet Working Group Shingala, Frank Berntsen, and Bluetooth SIG's Internet Working Group
for providing significant feedback and improvement proposals for this for providing significant feedback and improvement proposals for this
document. document.
8. References 8. References
8.1. Normative References 8.1. Normative References
skipping to change at page 16, line 11 skipping to change at page 17, line 6
"Neighbor Discovery Optimization for IPv6 over Low-Power "Neighbor Discovery Optimization for IPv6 over Low-Power
Wireless Personal Area Networks (6LoWPANs)", RFC 6775, Wireless Personal Area Networks (6LoWPANs)", RFC 6775,
November 2012. November 2012.
[RFC7136] Carpenter, B. and S. Jiang, "Significance of IPv6 [RFC7136] Carpenter, B. and S. Jiang, "Significance of IPv6
Interface Identifiers", RFC 7136, February 2014. Interface Identifiers", RFC 7136, February 2014.
8.2. Informative References 8.2. Informative References
[I-D.ietf-6man-default-iids] [I-D.ietf-6man-default-iids]
Gont, F., Cooper, A., Thaler, D., and W. Will, Gont, F., Cooper, A., Thaler, D., and S. LIU,
"Recommendation on Stable IPv6 Interface Identifiers", "Recommendation on Stable IPv6 Interface Identifiers",
draft-ietf-6man-default-iids-02 (work in progress), draft-ietf-6man-default-iids-03 (work in progress), May
January 2015. 2015.
[IEEE802-2001] [IEEE802-2001]
Institute of Electrical and Electronics Engineers (IEEE), Institute of Electrical and Electronics Engineers (IEEE),
"IEEE 802-2001 Standard for Local and Metropolitan Area "IEEE 802-2001 Standard for Local and Metropolitan Area
Networks: Overview and Architecture", 2002. Networks: Overview and Architecture", 2002.
[RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C.,
and M. Carney, "Dynamic Host Configuration Protocol for and M. Carney, "Dynamic Host Configuration Protocol for
IPv6 (DHCPv6)", RFC 3315, July 2003. IPv6 (DHCPv6)", RFC 3315, July 2003.
 End of changes. 16 change blocks. 
60 lines changed or deleted 105 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/