6Lo Working Group                                               C. Gomez
Internet-Draft                                               S. Darroudi
Intended status: Standards Track                               UPC/i2cat
Expires: May 17, September 12, 2017                                T. Savolainen
                                                       November 13, 2016
                                                          March 11, 2017

           IPv6 Mesh over BLUETOOTH(R) Low Energy using IPSP


   RFC 7668 describes the adaptation of 6LoWPAN techniques to enable
   IPv6 over Bluetooth low energy networks that follow the star
   topology.  However, recent Bluetooth specifications allow the
   formation of extended topologies as well.  This document specifies
   the mechanisms needed to enable IPv6 over mesh networks composed of
   Bluetooth low energy links established by using the Bluetooth
   Internet Protocol Support Profile.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on May 17, September 12, 2017.

Copyright Notice

   Copyright (c) 2016 2017 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
     1.1.  Terminology and Requirements Language . . . . . . . . . .   3
   2.  Bluetooth LE Networks and the IPSP  . . . . . . . . . . . . .   3
   3.  Specification of IPv6 mesh over Bluetooth LE networks . . . .   3
     3.1.  Protocol stack  . . . . . . . . . . . . . . . . . . . . .   4
     3.2.  Subnet model  . . . . . . . . . . . . . . . . . . . . . .   4
     3.3.  Link model  . . . . . . . . . . . . . . . . . . . . . . .   5
       3.3.1.  Stateless address autoconfiguration . . . . . . . . .   5
       3.3.2.  Neighbor Discovery  . . . . . . . . . . . . . . . . .   5
       3.3.3.  Header compression  . . . . . . . . . . . . . . . . .   6
       3.3.4.  Unicast and multicast mapping . . . . . . . . . . . .   7
   4.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   8
   5.  Security Considerations . . . . . . . . . . . . . . . . . . .   8
   6.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .   8
   7.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   8
     7.1.  Normative References  . . . . . . . . . . . . . . . . . .   9
     7.2.  Informative References  . . . . . . . . . . . . . . . . .   9
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  10

1.  Introduction

   Bluetooth low energy (hereinafter, Bluetooth LE) was first introduced
   in the Bluetooth 4.0 specification.  Bluetooth LE (which has been
   marketed as Bluetooth Smart) is a low-power wireless technology
   designed for short-range control and monitoring applications.
   Bluetooth LE is currently implemented in a wide range of consumer
   electronics devices, such as smartphones and wearable devices.  Given
   the high potential of this technology for the Internet of Things, the
   Bluetooth Special Interest Group (Bluetooth SIG) and the IETF have
   produced specifications in order to enable IPv6 over Bluetooth LE,
   such as the Internet Protocol Support Profile (IPSP) [IPSP], and RFC
   7668, respectively.  Bluetooth 4.0 only supports Bluetooth LE
   networks that follow the star topology.  In consequence, RFC 7668 was
   specifically developed and optimized for that type of network
   topology.  However, subsequent Bluetooth specifications allow the
   formation of extended topologies [BTCorev4.1], such as the mesh
   topology.  The functionality described in RFC 7668 is not sufficient
   and would fail to enable IPv6 over mesh networks composed of
   Bluetooth LE links.  This document specifies the mechanisms needed to
   enable IPv6 over mesh networks composed of Bluetooth LE links.  This
   specification also allows to run IPv6 over Bluetooth LE star topology
   networks, albeit without all the topology-specific optimizations
   contained in RFC 7668.

1.1.  Terminology and Requirements Language

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   document are to be interpreted as described in RFC 2119 [RFC2119].

   The terms 6LoWPAN Node (6LN), 6LoWPAN Router (6LR) and 6LoWPAN Border
   Router (6LBR) are defined as in [RFC6775], with an addition that
   Bluetooth LE central and Bluetooth LE peripheral (see Section 2) can
   both be adopted by a 6LN, a 6LR or a 6LBR.

2.  Bluetooth LE Networks and the IPSP

   Bluetooth LE defines two Generic Access Profile (GAP) roles of
   relevance herein: the Bluetooth LE central role and the Bluetooth LE
   peripheral role.  A device in the central role, which is called
   central from now on, has traditionally been able to manage multiple
   simultaneous connections with a number of devices in the peripheral
   role, called peripherals hereinafter.  Bluetooth 4.1 introduced the
   possibility for a peripheral to be connected to more than one central
   simultaneously, therefore allowing extended topologies beyond the
   star topology for a Bluetooth LE network.  In addition, a device may
   simultaneously be a central in a set of link layer connections, as
   well as a peripheral in others.  On the other hand, the IPSP enables
   discovery of IP-enabled devices and the establishment of a link layer
   connection for transporting IPv6 packets.  The IPSP defines the Node
   and Router roles for devices that consume/originate IPv6 packets and
   for devices that can route IPv6 packets, respectively.  Consistently
   with Bluetooth 4.1, a device may implement both roles simultaneously.

   This document assumes a mesh network composed of Bluetooth LE links,
   where link layer connections have been established between
   neighboring IPv6-enabled devices.  The IPv6 forwarding devices of the
   mesh have to implement both Node and Router roles, while simpler
   leaf-only nodes can implement only the Node role.  In an IPv6-enabled
   mesh of Bluetooth LE links, a node is a neighbor of another node, and
   vice versa, if a link layer connection has been established between
   both by using the IPSP functionality for discovery and link layer
   connection establishment for IPv6 packet transport.

3.  Specification of IPv6 mesh over Bluetooth LE networks
3.1.  Protocol stack

   Figure 1 illustrates the protocol stack for IPv6 mesh over Bluetooth
   LE networks.  There are two main differences with the IPv6 over
   Bluetooth LE stack in RFC 7668: a) the adaptation layer below IPv6
   (labelled as "6Lo for IPv6 mesh of Bluetooth LE") is now adapted for
   mesh networks of Bluetooth LE links, and b) the protocol stack for
   IPv6 mesh networks of Bluetooth LE links includes IPv6 routing

                         |             Application            |
            +---------+  +------------------------------------+
            |  IPSS   |  |            UDP/TCP/other           |
            +---------+  +------------------------------------+
            |  GATT   |  |             IPv6  |routing|        |
            +---------+  +------------------------------------+
            |  ATT    |  | 6Lo for IPv6 mesh over Bluetooh LE |
            |                 Bluetooth LE L2CAP              |
       -  - +-------------------------------------------------+- - - HCI
            |               Bluetooth LE Link Layer           |
            |                Bluetooth LE Physical            |

         Figure 1: Protocol stack for IPv6 mesh over Bluetooth LE.

3.2.  Subnet model

   For IPv6 mesh over Bluetooth LE, a multilink model has been chosen,
   as further illustrated in Figure 2.  As IPv6 over Bluetooth LE is
   intended for constrained nodes, and for Internet of Things use cases
   and environments, the complexity of implementing a separate subnet on
   each peripheral-central link and routing between the subnets appears
   to be excessive.  In this specification, the benefits of treating the
   collection of point-to-point links between a central and its
   connected peripherals as a single multilink subnet rather than a
   multiplicity of separate subnets are considered to outweigh the
   multilink model's drawbacks as described in [RFC4903].

       .--------------------------------.                /
      /     6LR           6LN        6LN \              /
     /         \             \          \ \            /
    |           \             \          \ |          /
    |  6LN ----- 6LR --------- 6LR ------ 6LBR ----- |  Internet
    |   <--Link--> <---Link--->/<--Link->/ |         |
     \                        /         / /           \
      \           6LN ---- 6LR ----- 6LR /             \
       '--------------------------------'               \

     <------------ Subnet -----------------><---- IPv6 connection -->
                                                  to the Internet

       Figure 2: Example of an IPv6 mesh over a Bluetooth LE network
                         connected to the Internet

   One or more 6LBRs are connected to the Internet. 6LNs are connected
   to the network through a 6LR or a 6LBR.  A prefix is used on the
   whole subnet.

   IPv6 mesh networks over Bluetooth LE MUST follow a route-over
   approach.  This document does not specify the routing protocol to be
   used in an IPv6 mesh over Bluetooth LE.

3.3.  Link model

3.3.1.  Stateless address autoconfiguration

   6LN, 6LR and 6LBR IPv6 addresses in an IPv6 mesh over Bluetooth LE
   are configured as per section 3.2.2 of RFC 7668.

   Multihop DAD functionality as defined in section 8.2 of RFC 6775, or
   some substitute mechanism (see section 3.3.2), MUST be supported.

3.3.2.  Neighbor Discovery

   'Neighbor Discovery Optimization for IPv6 over Low-Power Wireless
   Personal Area Networks (6LoWPANs)' [RFC6775] describes the neighbor
   discovery approach as adapted for use in several 6LoWPAN topologies,
   including the mesh topology.  The route-over functionality of RFC
   6775 MUST be supported.

   The following aspects of the Neighbor Discovery optimizations
   [RFC6775] are applicable to Bluetooth LE 6LNs:

   1.  A Bluetooth LE 6LN MUST NOT register its link-local address.  A
   Bluetooth LE 6LN host MUST register its non-link-local addresses with its
   routers by sending a Neighbor Solicitation (NS) message with the
   Address Registration Option (ARO) and process the Neighbor
   Advertisement (NA) accordingly.  The NS with the ARO option MUST be
   sent irrespective of the method used to generate the IID.  The ARO
   option requires use of an EUI-64 identifier [RFC6775].  In the 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 Modified
   EUI-64 format [RFC4291].

   If the 6LN registers for a same compression context multiple
   addresses that are not based on Bluetooth device address, the header
   compression efficiency will decrease.

   2.  For sending Router Solicitations and processing Router
   Advertisements the Bluetooth LE 6LNs hosts MUST, respectively, follow
   Sections 5.3 and 5.4 of the [RFC6775].

   3.  The router behavior for 6LRs and 6LBRs is described in Section 6
   of RFC 6775.  However, as per this specification, routers SHALL NOT
   use multicast NSs to discover other routers' link layer addresses.

   4.  Border router behavior is described in Section 7 of RFC 6775.

   RFC 6775 defines substitutable mechanisms for distributing prefixes
   and context information (section 8.1 of RFC 6775), as well as for
   Duplicate Address Detection across a route-over 6LoWPAN (section 8.2
   of RFC 6775).  Implementations of this specification MUST support the
   features described in sections 8.1 and 8.2 of RFC 6775 unless some
   alternative ("substitute") from some other specification is

3.3.3.  Header compression

   Header compression as defined in RFC 6282 [RFC6282], which specifies
   the compression format for IPv6 datagrams on top of IEEE 802.15.4, is
   REQUIRED as the basis for IPv6 header compression on top of Bluetooth
   LE.  All headers MUST be compressed according to RFC 6282 [RFC6282]
   encoding formats.

   To enable efficient header compression, when the 6LBR sends a Router
   Advertisement it MUST include a 6LoWPAN Context Option (6CO)
   [RFC6775] matching each address prefix advertised via a Prefix
   Information Option (PIO) [RFC4861] for use in stateless address

   The specific optimizations of RFC 7668 for header compression, which
   exploit the star topology and ARO, cannot be generalized in a mesh
   network composed of Bluetooth LE links.  Still, a subset of those
   optimizations can be applied in some cases in such a network.  In
   particular, the latter comprise link-local interactions, non-link-
   local packet transmissions originated and performed by a 6LN, and
   non-link-local packet transmissions originated packets transmitted (but not necessarily originated)
   by the neighbor of a 6LN neighbor and
   sent to a that 6LN.  For the rest of packet
   transmissions, context-based compression MAY be used.

   When a device transmits a packet to a neighbor, the sender MUST fully
   elide the source IID if the source IPv6 address is the link-local
   address based on the sender's Bluetooth device address (SAC=0,
   SAM=11).  The sender also MUST fully elide the destination IPv6
   address if it is the link-local-address based on the neighbor's
   Bluetooth device address (DAC=0, DAM=11).

   When a 6LN transmits a packet, with a non-link-local source address
   that the 6LN has registered with ARO in the next-hop router for the
   indicated prefix, the source address MUST be fully elided if it is
   the latest address that the 6LN has registered for the indicated
   prefix (SAC=1, SAM=11).  If the source non-link-local address is not
   the latest registered by the 6LN, then the 64-bits of the IID SHALL
   be fully carried in-line (SAC=1, SAM=01) or if the first 48-bits of
   the IID match with the latest address registered by the 6LN, then the
   last 16-bits of the IID SHALL be carried in-line (SAC=1, SAM=10).

   When a router transmits a packet to a neighboring 6LN, with a non-
   link-local destination address, the router MUST fully elide the
   destination IPv6 address if the destination 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 the 6LN MUST either include the IID
   part fully in-line (DAM=01) or, if the first 48-bits of the IID match
   to the latest registered address, then elide those 48-bits (DAM=10).

3.3.4.  Unicast and multicast mapping

   The Bluetooth LE Link Layer does not support multicast.  Hence,
   traffic is always unicast between two Bluetooth LE neighboring nodes.
   If a node needs to send a multicast packet to several neighbors, it
   has to replicate the packet and unicast it on each link.  However,
   this may not be energy efficient, and particular care must be taken
   if the node is battery powered.  A router (i.e. a 6LR or a 6LBR) MUST
   keep track of neighboring multicast listeners, and it MUST NOT
   forward multicast packets to neighbors that have not registered as
   listeners for multicast groups the packets belong to.

4.  IANA Considerations

   There are no IANA considerations related to this document.

5.  Security Considerations

   The security considerations in RFC 7668 apply.

   IPv6 mesh networks over Bluetooth LE require a routing protocol to
   find end-to-end paths.  Unfortunately, the routing protocol may
   generate additional opportunities for threats and attacks to the

   RFC 7416 [RFC 7416] provides a systematic overview of threats and
   attacks on the IPv6 Routing Protocol for Low-Power and Lossy Networks
   (RPL), as well as countermeasures.  In that document, described
   threats and attacks comprise threats due to failures to authenticate,
   threats due to failure to keep routing information, threats and
   attacks on integrity, and threats and attacks on availability.
   Reported countermeasures comprise confidentiality attack, integrity
   attack, and availability attack countermeasures.

   While this specification does not state the routing protocol to be
   used in IPv6 mesh over Bluetooth LE networks, the guidance of RFC
   7416 is useful when RPL is used in such scenarios.  Furthermore, such
   guidance may partly apply for other routing protocols as well.

6.  Acknowledgements

   The Bluetooth, Bluetooth Smart and Bluetooth Smart Ready marks are
   registered trademarks owned by Bluetooth SIG, Inc.

   The authors of this document are grateful to all RFC 7668 authors,
   since this document borrows many concepts (albeit, with necessary
   extensions) from RFC 7668.

   The authors also thank Alain Michaud, Mark Powell and Martin Turon
   for their comments, which helped improve the document.

   Carles Gomez has been supported in part by the Spanish Government
   Ministerio de Economia y Competitividad through project
   TEC2012-32531, and FEDER.

7.  References
7.1.  Normative References

              Bluetooth Special Interest Group, "Bluetooth Core
              Specification Version 4.1", December 2013,

   [IPSP]     Bluetooth Special Interest Group, "Bluetooth Internet
              Protocol Support Profile Specification Version 1.0.0",
              December 2014, <https://www.bluetooth.org/en-

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,

   [RFC4291]  Hinden, R. and S. Deering, "IP Version 6 Addressing
              Architecture", RFC 4291, DOI 10.17487/RFC4291, February
              2006, <http://www.rfc-editor.org/info/rfc4291>.

   [RFC4861]  Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
              "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,
              DOI 10.17487/RFC4861, September 2007,

   [RFC6282]  Hui, J., Ed. and P. Thubert, "Compression Format for IPv6
              Datagrams over IEEE 802.15.4-Based Networks", RFC 6282,
              DOI 10.17487/RFC6282, September 2011,

   [RFC6775]  Shelby, Z., Ed., Chakrabarti, S., Nordmark, E., and C.
              Bormann, "Neighbor Discovery Optimization for IPv6 over
              Low-Power Wireless Personal Area Networks (6LoWPANs)",
              RFC 6775, DOI 10.17487/RFC6775, November 2012,

   [RFC7668]  Nieminen, J., Savolainen, T., Isomaki, M., Patil, B.,
              Shelby, Z., and C. Gomez, "IPv6 over BLUETOOTH(R) Low
              Energy", RFC 7668, DOI 10.17487/RFC7668, October 2015,

7.2.  Informative References

   [RFC4903]  Thaler, D., "Multi-Link Subnet Issues", RFC 4903,
              DOI 10.17487/RFC4903, June 2007,

   [RFC7416]  Tsao, T., Alexander, R., Dohler, M., Daza, V., Lozano, A.,
              and M. Richardson, Ed., "A Security Threat Analysis for
              the Routing Protocol for Low-Power and Lossy Networks
              (RPLs)", RFC 7416, DOI 10.17487/RFC7416, January 2015,

Authors' Addresses

   Carles Gomez
   Universitat Politecnica de Catalunya/Fundacio i2cat
   C/Esteve Terradas, 7
   Castelldefels  08860

   Email: carlesgo@entel.upc.edu

   Seyed Mahdi Darroudi
   Universitat Politecnica de Catalunya/Fundacio i2cat
   C/Esteve Terradas, 7
   Castelldefels  08860

   Email: sm.darroudi@entel.upc.edu

   Teemu Savolainen
   Nokia Technologies
   Hatanpaan valtatie 30
   Tampere  33100

   Email: teemu.savolainen@nokia.com