draft-ietf-6lo-btle-01.txt   draft-ietf-6lo-btle-02.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: November 3, 2014 Nokia Expires: December 13, 2014 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
May 2, 2014 June 11, 2014
Transmission of IPv6 Packets over BLUETOOTH(R) Low Energy Transmission of IPv6 Packets over BLUETOOTH(R) Low Energy
draft-ietf-6lo-btle-01 draft-ietf-6lo-btle-02
Abstract Abstract
Bluetooth Smart is the brand name for the low energy feature in the Bluetooth Smart is the brand name for the Bluetooth low energy
Bluetooth specification defined by the Bluetooth Special Interest feature in the Bluetooth specification defined by the Bluetooth
Group. The standard Bluetooth radio has been widely implemented and Special Interest Group. The standard Bluetooth radio has been widely
available in mobile phones, notebook computers, audio headsets and implemented and available in mobile phones, notebook computers, audio
many other devices. The low power version of Bluetooth is a headsets and many other devices. The low power version of Bluetooth
specification that enables the use of this air interface with devices is a specification that enables the use of this air interface with
such as sensors, smart meters, appliances, etc. The low power devices such as sensors, smart meters, appliances, etc. The low
variant of Bluetooth is standardized since the revision 4.0 of the power variant of Bluetooth is standardized since the revision 4.0 of
Bluetooth specifications, although version 4.1 or newer is required the Bluetooth specifications, although version 4.1 or newer is
for IPv6. This document describes how IPv6 is transported over required for IPv6. This document describes how IPv6 is transported
Bluetooth Low Energy using 6LoWPAN techniques. over Bluetooth low energy using 6LoWPAN techniques.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
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 November 3, 2014. This Internet-Draft will expire on December 13, 2014.
Copyright Notice Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the Copyright (c) 2014 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 25 skipping to change at page 2, line 25
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
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Terminology and Requirements Language . . . . . . . . . . 3 1.1. Terminology and Requirements Language . . . . . . . . . . 3
2. Bluetooth Low Energy . . . . . . . . . . . . . . . . . . . . 3 2. Bluetooth Low Energy . . . . . . . . . . . . . . . . . . . . 3
2.1. Bluetooth Low Energy stack . . . . . . . . . . . . . . . 4 2.1. Bluetooth LE stack . . . . . . . . . . . . . . . . . . . 4
2.2. Link layer roles and topology . . . . . . . . . . . . . . 4 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 . . . . . . . . . . . 6
3. Specification of IPv6 over Bluetooth Low Energy . . . . . . . 6 3. Specification of IPv6 over Bluetooth Low Energy . . . . . . . 6
3.1. Protocol stack . . . . . . . . . . . . . . . . . . . . . 6 3.1. Protocol stack . . . . . . . . . . . . . . . . . . . . . 6
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 . . . . . . . . . . . . . . . . . 8 3.2.2. Neighbor discovery . . . . . . . . . . . . . . . . . 8
3.2.3. Header compression . . . . . . . . . . . . . . . . . 9 3.2.3. Header compression . . . . . . . . . . . . . . . . . 9
3.2.3.1. Remote destination example . . . . . . . . . . . 10 3.2.3.1. Remote destination example . . . . . . . . . . . 10
3.2.4. Unicast and Multicast address mapping . . . . . . . . 11 3.2.4. Unicast and Multicast address mapping . . . . . . . . 11
3.3. Internet connectivity scenarios . . . . . . . . . . . . . 11 3.3. Internet connectivity scenarios . . . . . . . . . . . . . 11
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
skipping to change at page 3, line 29 skipping to change at page 3, line 29
Bluetooth LE links. This document specifies the details of IPv6 Bluetooth LE links. This document specifies the details of IPv6
transmission over Bluetooth LE links. transmission over Bluetooth LE links.
1.1. Terminology and Requirements Language 1.1. Terminology and Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119]. document are to be interpreted as described in RFC 2119 [RFC2119].
The terms 6LN, 6LR and 6LBR are defined as in [RFC6775], with an The terms 6LN, 6LR and 6LBR are defined as in [RFC6775], with an
addition that Bluetooth LE central and Bluetooth LE peripheral can addition that Bluetooth LE central and Bluetooth LE peripheral (see
both be either 6LN or 6LBR. Section 2.2) can both be either 6LN or 6LBR.
2. Bluetooth Low Energy 2. Bluetooth Low Energy
Bluetooth LE is designed for transferring small amounts of data Bluetooth LE is designed for transferring small amounts of data
infrequently at modest data rates at a very low cost per bit. infrequently at modest data rates at a very low cost per bit.
Bluetooth Special Interest Group (Bluetooth SIG) has introduced two Bluetooth Special Interest Group (Bluetooth SIG) has introduced two
trademarks, Bluetooth Smart for single-mode devices (a device that trademarks, Bluetooth Smart for single-mode devices (a device that
only supports Bluetooth LE) and Bluetooth Smart Ready for dual-mode only supports Bluetooth LE) and Bluetooth Smart Ready for dual-mode
devices. In the rest of the document, the term Bluetooth LE refers devices (devices that support both Bluetooth and Bluetooth LE). In
to both types of devices. the rest of the document, the term Bluetooth LE refers to both types
of devices.
Bluetooth LE was introduced in Bluetooth 4.0 and further enhanced in Bluetooth LE was introduced in Bluetooth 4.0 and further enhanced in
Bluetooth 4.1 [BTCorev4.1]. Bluetooth SIG will also publish Internet Bluetooth 4.1 [BTCorev4.1]. Bluetooth SIG will also publish Internet
Protocol Support Profile (IPSP) [IPSP], which includes Internet Protocol Support Profile (IPSP) [IPSP], which includes Internet
Protocol Support Service (IPSS) and that enables discovery of IP- Protocol Support Service (IPSS) and that enables discovery of IP-
enabled devices and establishment of link-layer connection for enabled devices and establishment of link-layer connection for
transporting IPv6 packets. IPv6 over Bluetooth LE is dependent on transporting IPv6 packets. IPv6 over Bluetooth LE is dependent on
both Bluetooth 4.1 and IPSP. both Bluetooth 4.1 and IPSP.
Devices such as mobile phones, notebooks, tablets and other handheld Devices such as mobile phones, notebooks, tablets and other handheld
computing devices which will include Bluetooth 4.1 chipsets will also computing devices which will include Bluetooth 4.1 chipsets will also
have the low-energy functionality of Bluetooth. Bluetooth LE will have the low-energy functionality of Bluetooth. Bluetooth LE will
also be included in many different types of accessories that also be included in many different types of accessories that
collaborate with mobile devices such as phones, tablets and notebook collaborate with mobile devices such as phones, tablets and notebook
computers. An example of a use case for a Bluetooth LE accessory is computers. An example of a use case for a Bluetooth LE accessory is
a heart rate monitor that sends data via the mobile phone to a server a heart rate monitor that sends data via the mobile phone to a server
on the Internet. on the Internet.
2.1. Bluetooth Low Energy stack 2.1. Bluetooth LE stack
The lower layer of the Bluetooth LE stack consists of the Physical The lower layer of the Bluetooth LE stack consists of the Physical
(PHY) and the Link Layer (LL). The Physical Layer transmits and (PHY) and the Link Layer (LL). The Physical Layer transmits and
receives the actual packets. The Link Layer is responsible for receives the actual packets. The Link Layer is responsible for
providing medium access, connection establishment, error control and providing medium access, connection establishment, error control and
flow control. The upper layer consists of the Logical Link Control flow control. The upper layer consists of the Logical Link Control
and Adaptation Protocol (L2CAP), Attribute Protocol (ATT), Generic and Adaptation Protocol (L2CAP), Attribute Protocol (ATT), Generic
Attribute Profile (GATT) and Generic Access Profile (GAP) as shown in Attribute Profile (GATT) and Generic Access Profile (GAP) as shown in
Figure 1. The device internal Host Controller Interface (HCI) Figure 1. The device internal Host Controller Interface (HCI)
separates the lower layers, often implemented in the Bluetooth separates the lower layers, often implemented in the Bluetooth
skipping to change at page 4, line 47 skipping to change at page 5, line 7
- - -+-----------------------+-------------------------+- - - HCI - - -+-----------------------+-------------------------+- - - HCI
| Link Layer | Direct Test Mode | | Link Layer | Direct Test Mode |
+-------------------------------------------------+ +-------------------------------------------------+
| Physical Layer | | Physical Layer |
+-------------------------------------------------+ +-------------------------------------------------+
Figure 1: Bluetooth LE Protocol Stack Figure 1: Bluetooth LE Protocol Stack
2.2. Link layer roles and topology 2.2. Link layer roles and topology
Bluetooth LE defines two Link Layer roles: the Bluetooth LE central Bluetooth LE defines two GAP roles of relevance herein: the Bluetooth
role and the Bluetooth LE peripheral role. A device in the central LE central role and the Bluetooth LE peripheral role. A device in
role, which is called central from now on, has traditionally been the central role, which is called central from now on, has
able to manage multiple simultaneous connections with a number of traditionally been able to manage multiple simultaneous connections
devices in the peripheral role, called peripherals from now on. A with a number of devices in the peripheral role, called peripherals
peripheral is commonly connected to a single central, but since from now on. A peripheral is commonly connected to a single central,
Bluetooth 4.1 can also connect to multiple centrals. In this but since Bluetooth 4.1 can also connect to multiple centrals. In
document for IPv6 networking purposes the Bluetooth LE network (i.e. this document for IPv6 networking purposes the Bluetooth LE network
a Bluetooth LE piconet) follows a star topology shown in the (i.e. a Bluetooth LE piconet) follows a star topology shown in the
Figure 2, where the router typically implements the Bluetooth LE Figure 2, where the router typically implements the Bluetooth LE
central role and nodes Bluetooth LE peripheral roles. In the future central role and nodes implement the Bluetooth LE peripheral role.
mesh networking may be defined for IPv6 over Bluetooth LE. In the future mesh networking may be defined for IPv6 over Bluetooth
LE.
Node --. .-- Node Node --. .-- Node
\ / \ /
Node ---- Router ---- Node Node ---- Router ---- Node
/ \ / \
Node --' '-- Node Node --' '-- Node
Figure 2: Bluetooth LE Star Topology Figure 2: Bluetooth LE Star Topology
In Bluetooth LE a central is assumed to be less constrained than a In Bluetooth LE a central is assumed to be less constrained than a
skipping to change at page 6, line 6 skipping to change at page 6, line 15
2.4. Bluetooth LE packets sizes and MTU 2.4. Bluetooth LE packets sizes and MTU
Optimal MTU defined for L2CAP fixed channels over Bluetooth LE is 27 Optimal MTU defined for L2CAP fixed channels over Bluetooth LE is 27
bytes including the L2CAP header of four bytes. Default MTU for bytes including the L2CAP header of four bytes. Default MTU for
Bluetooth LE is hence defined to be 27 bytes. Therefore, excluding Bluetooth LE is hence defined to be 27 bytes. Therefore, excluding
L2CAP header of four bytes, protocol data unit (PDU) size of 23 bytes L2CAP header of four bytes, protocol data unit (PDU) size of 23 bytes
is available for upper layers. In order to be able to transmit IPv6 is available for upper layers. In order to be able to transmit IPv6
packets of 1280 bytes or larger, link layer fragmentation and packets of 1280 bytes or larger, link layer fragmentation and
reassembly solution is provided by the L2CAP layer. The IPSP defines reassembly solution is provided by the L2CAP layer. The IPSP defines
means for negotiating up a link-layer connection that provides MTU of means for negotiating up a link-layer connection that provides MTU of
1280 bytes or higher for the IPv6 layer [IPSP]. 1280 bytes or higher for the IPv6 layer [IPSP]. The link-layer MTU
is negotiated separately for each direction. Implementations that
require single link-layer MTU value SHALL use the smallest of the
possibly different MTU values.
3. Specification of IPv6 over Bluetooth Low Energy 3. Specification of IPv6 over Bluetooth Low Energy
Before any IP-layer communications can take place over Bluetooth LE, Before any IP-layer communications can take place over Bluetooth LE,
Bluetooth LE enabled nodes such as 6LNs and 6LBRs have to find each Bluetooth LE enabled nodes such as 6LNs and 6LBRs have to find each
other and establish a suitable link-layer connection. The discovery other and establish a suitable link-layer connection. The discovery
and Bluetooth LE connection setup procedures are documented by and Bluetooth LE connection setup procedures are documented by
Bluetooth SIG in the IPSP specification [IPSP], and hence are out of Bluetooth SIG in the IPSP specification [IPSP], and hence are out of
scope of this document. The IPSP depends on Bluetooth version 4.1, scope of this document. The IPSP depends on Bluetooth version 4.1,
and hence both Bluetooth version 4.1 or newer and IPSP are required and hence both Bluetooth version 4.1 or newer and IPSP are required
skipping to change at page 6, line 39 skipping to change at page 6, line 51
that the former supports both star and mesh topology (and requires a that the former supports both star and mesh topology (and requires a
routing protocol), whereas Bluetooth LE does not currently support routing protocol), whereas Bluetooth LE does not currently support
the formation of multihop networks at the link layer. the formation of multihop networks at the link layer.
3.1. Protocol stack 3.1. Protocol stack
Figure 3 illustrates IPv6 over Bluetooth LE stack including the Figure 3 illustrates IPv6 over Bluetooth LE stack including the
Internet Protocol Support Service. UDP and TCP are provided as Internet Protocol Support Service. UDP and TCP are provided as
examples of transport protocols, but the stack can be used by any examples of transport protocols, but the stack can be used by any
other upper layer protocol capable of running atop of IPv6. The other upper layer protocol capable of running atop of IPv6. The
6LoWPAN runs on top of Bluetooth LE L2CAP layer. 6LoWPAN layer runs on top of Bluetooth LE L2CAP layer.
+---------+ +----------------------------+ +---------+ +----------------------------+
| IPSS | | UDP/TCP/other | | IPSS | | UDP/TCP/other |
+---------+ +----------------------------+ +---------+ +----------------------------+
| GATT | | IPv6 | | GATT | | IPv6 |
+---------+ +----------------------------+ +---------+ +----------------------------+
| ATT | | 6LoWPAN adapted to LE | | ATT | | 6LoWPAN for Bluetooth LE |
+---------+--+----------------------------+ +---------+--+----------------------------+
| Bluetooth LE L2CAP | | Bluetooth LE L2CAP |
- - +-----------------------------------------+- - - HCI - - +-----------------------------------------+- - - HCI
| Bluetooth LE Link Layer | | Bluetooth LE Link Layer |
+-----------------------------------------+ +-----------------------------------------+
| Bluetooth LE Physical | | Bluetooth LE Physical |
+-----------------------------------------+ +-----------------------------------------+
Figure 3: IPv6 over Bluetooth LE Stack Figure 3: IPv6 over Bluetooth LE Stack
skipping to change at page 7, line 41 skipping to change at page 7, line 41
In the case of Bluetooth LE, 6LoWPAN layer is adapted to support In the case of Bluetooth LE, 6LoWPAN layer is adapted to support
transmission of IPv6 packets over Bluetooth LE. The IPSP defines all transmission of IPv6 packets over Bluetooth LE. The IPSP defines all
steps required for setting up the Bluetooth LE connection over which steps required for setting up the Bluetooth LE connection over which
6LoWPAN can function [IPSP], including handling the link-layer 6LoWPAN can function [IPSP], including handling the link-layer
fragmentation required on Bluetooth LE, as described in Section 2.4. fragmentation required on Bluetooth LE, as described in Section 2.4.
This specification also assumes the IPv6 header compression format This specification also assumes the IPv6 header compression format
specified in RFC 6282 is used [RFC6282]. It is also assumed that the specified in RFC 6282 is used [RFC6282]. It is also assumed that the
IPv6 payload length can be inferred from the L2CAP header length and IPv6 payload length can be inferred from the L2CAP header length and
the IID value inferred from the link-layer address with help of the IID value inferred from the link-layer address with help of
Neighbor Cache, if elided from compressed packet. Neighbor Cache, if elided from compressed packet header.
The Bluetooth LE link between two communicating nodes can be Bluetooth LE connections used to build a star topology are point-to-
considered to be a point-to-point or point-to-multipoint link. When point in nature, as Bluetooth broadcast features are not used for
one of the communicating nodes is simultaneously connected to IPv6 over Bluetooth LE. 6LN-to-6LN communications, e.g. using link-
multiple nodes, the link can be viewed as a point-to-multipoint link local addresses, need to be bridged by the 6LBR. The 6LBR ensures
from the particular node point of view. However, due to Bluetooth LE address collisions do not occur (see Section 3.2.2).
star topology, each branch of the star is considered to be an
individual link and thus only two nodes can directly talk to each
other. Node-to-node communications, e.g. using link-local addresses,
need to be bridged by the 6LBR. The 6LBR ensures address collisions
do not occur (see Section 3.2.2).
After the peripheral and central have connected at the Bluetooth LE After the peripheral and central have connected at the Bluetooth LE
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
A Bluetooth LE 6LN performs stateless address autoconfiguration as A Bluetooth LE 6LN performs stateless address autoconfiguration as
per RFC 4862 [RFC4862]. A 64-bit Interface identifier (IID) for a per RFC 4862 [RFC4862]. A 64-bit Interface identifier (IID) for a
Bluetooth LE interface MAY be formed by utilizing the 48-bit Bluetooth LE interface MAY be formed by utilizing the 48-bit
skipping to change at page 9, line 13 skipping to change at page 9, line 8
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 addresses with the 6LBR by 1. A Bluetooth LE 6LN MUST register its addresses with the 6LBR by
sending a Neighbor Solicitation (NS) message with the Address 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 SHOULD be sent irrespective accordingly. The NS with the ARO option MUST be sent irrespective of
of the method used to generate the IID. The 6LN MUST register only the method used to generate the IID. The 6LN MUST register only one
one IPv6 address per IPv6 prefix available on a link. IPv6 address per IPv6 prefix available on a link.
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 9, line 39 skipping to change at page 9, line 34
The Bluetooth LE's star topology structure and ARO can be exploited The Bluetooth LE's star topology structure and ARO can be exploited
in order to provide a mechanism for IID compression. The following in order to provide a mechanism for IID compression. The following
text describes the principles of IPv6 address compression on top of text describes the principles of IPv6 address compression on top of
Bluetooth LE. Bluetooth LE.
The ARO option requires use of EUI-64 identifier [RFC6775]. In the The ARO option requires use of EUI-64 identifier [RFC6775]. In the
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
Context Option (6CO) [RFC6775] for all prefixes the 6LBR advertises
in Router Advertisements for use in stateless address
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 the source IPv6 address is currently elide the source address it has registered with ARO to the 6LBR for
registed with ARO to the 6LBR and the 6LN has registered only one the indicated prefix. That is, if SAC=0 and SAM=11 the 6LN MUST have
address for the indicated prefix. That is, if SAC=0 and SAM=11 the registered the source link-local IPv6 address it is using using ARO,
6LN MUST have registered the source link-local IPv6 address it is and if SAC=1 and SAM=11 the 6LN MUST have registered the source IPv6
using using ARO, and if SAC=1 and SAM=11 the 6LN MUST have registered address with the prefix related to compression context identified
the source IPv6 address with the prefix related to compression with Context Identifier Extension. The destination IPv6 address MUST
context identified with Context Identifier Extension. The be fully elided if the destination address is the same address to
destination IPv6 address MUST be fully elided if the destination which the 6LN has succesfully registered its source IPv6 address with
address is the same address to which the 6LN has succesfully ARO (set DAC=0, DAM=11). The destination IPv6 address MUST be fully
registered its source IPv6 address with ARO (set DAC=0, DAM=11). The or partially elided if context has been set up for the destination
destination IPv6 address MUST be fully or partially elided if the address. For example, DAC=0 and DAM=01 when destination prefix is
destination address has prefix for which context has been set up, for link-local, and DAC=1 and DAM=01 with Context Identifier Extension if
example, DAC=0 and DAM=01 when destination is link-local, and DAC=1 compression context has been configured for the used destination
and DAM=01 with Context Identifier Extension if compression context prefix.
has been configured for the used destination.
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 one 6LN has used to
register its address with ARO (set SAC=0, SAM=11), and it MUST elide register its address with ARO (set 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 elide the
destination IPv6 address if it is currently registered by the 6LN destination IPv6 address registered by the 6LN with ARO and thus 6LN
with ARO and thus 6LN can determine it based on indication of link- can determine it based on indication of link-local prefix (DAC=0) or
local prefix (DAC=0) or indication of other prefix (DAC=1 with indication of other prefix (DAC=1 with Context Identifier Extension).
Context Identifier Extension).
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 prefix global Unicast IPv6 addresses, if a context is defined for the 6LN's
of the 6LNs global IPv6 address, the 6LN has to indicate this context global IPv6 address, the 6LN has to indicate this context in the
in the corresponding source fields of the compressed IPv6 header as corresponding source fields of the compressed IPv6 header as per
per Section 3.1 of RFC 6282 [RFC6282], and has to elide the 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. For this, the 6LN
MUST use the following settings in the IPv6 compressed header: CID=1, MUST use the following settings in the IPv6 compressed header: CID=1,
SAC=1, SAM=11. In this case, the 6LBR can infer the elided IPv6 SAC=1, SAM=11. In this case, the 6LBR can infer the elided IPv6
source address since 1) the 6LBR has previously assigned the prefix source address since 1) the 6LBR has previously assigned the prefix
to the 6LNs; and 2) the 6LBR maintains a Neighbor Cache that relates to the 6LNs; and 2) the 6LBR maintains a Neighbor Cache that relates
the Device Address and the IID the device has registered with ARO. the Device Address and the IID the device has registered with ARO.
If a context is defined for the IPv6 destination address, the 6LN has If a context is defined for the IPv6 destination address, the 6LN has
to also indicate this context in the corresponding destination fields to also indicate this context in the corresponding destination fields
of the compressed IPv6 header, and elide the prefix of the of the compressed IPv6 header, and elide the prefix of or the full
destination IPv6 address. For this, the 6LN MUST set the DAM field destination IPv6 address. For this, the 6LN MUST set the DAM field
of the compressed IPv6 header as DAM=01 (if the context covers a of the compressed IPv6 header as DAM=01 (if the context covers a
64-bit prefix) or as DAM=11 (if the context covers a full, 128-bit 64-bit prefix) or as DAM=11 (if the context covers a full, 128-bit
address). CID and DAC MUST be set to CID=1 and DAC=1. Note that address). CID and DAC MUST be set to CID=1 and DAC=1. Note that
when a context is defined for the IPv6 destination address, the 6LBR when a context is defined for the IPv6 destination address, the 6LBR
can infer the elided destination prefix by using the context. 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. CID and DAC needs to be set to CID=1 and DAC=1. If a
context is defined for the prefix of the IPv6 source address, the context is defined for the IPv6 source address, the 6LBR needs to
6LBR needs to indicate this context in the source fields of the indicate this context in the source fields of the compressed IPv6
compressed IPv6 header, and elide that prefix as well. For this, the header, and elide that prefix as well. For this, the 6LBR needs to
6LBR needs to set the SAM field of the IPv6 compressed header as set the SAM field of the IPv6 compressed header as SAM=01 (if the
SAM=01 (if the context covers a 64-bit prefix) or SAM=11 (if the context covers a 64-bit prefix) or SAM=11 (if the context covers a
context covers a full, 128-bit address). CID and SAC are to be set full, 128-bit address). CID and SAC are to be set to CID=1 and
to CID=1 and SAC=1. SAC=1.
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-
powered. In the opposite direction, a 6LN can only transmit data to powered. In the opposite direction, a 6LN always has to send packets
a single destination (i.e. the 6LBR). Hence, when a 6LN needs to to or through 6LBR. Hence, when a 6LN needs to transmit an IPv6
transmit an IPv6 multicast packet, the 6LN will unicast the multicast packet, the 6LN will unicast the corresponding Bluetooth LE
corresponding Bluetooth LE packet to the 6LBR. The 6LBR will then packet to the 6LBR. The 6LBR will then forward the multicast packet
forward the multicast packet to other 6LNs. To avoid excess unwanted to other 6LNs. To avoid excess of unwanted multicast traffic being
multicast traffic being sent to 6LNs, the 6LBR SHOULD implement MLD sent to 6LNs, the 6LBR SHOULD implement MLD Snooping feature
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 5.
6LN 6LN
\ ____________ \ ____________
\ / \ \ / \
6LN ---- 6LBR ----- | Internet | 6LN ---- 6LBR ----- | Internet |
 End of changes. 25 change blocks. 
89 lines changed or deleted 92 lines changed or added

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