<?xml version="1.0" encoding="US-ASCII"?>
<!-- This template is for creating an Internet Draft using xml2rfc,
    which is available here: http://xml.resource.org. --> encoding="UTF-8"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!-- One method to get references from the online citation libraries.
    There has to be one entity for each item to be referenced.
    An alternate method (rfc include) is described in the references. -->

<!ENTITY RFC2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY RFC4291 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4291.xml">
<!ENTITY RFC4861 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4861.xml">
<!ENTITY RFC4903 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4903.xml">
<!ENTITY RFC6282 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6282.xml">
  <!ENTITY RFC4193 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4193.xml"> nbsp    "&#160;">
  <!ENTITY RFC6775 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6775.xml"> zwsp   "&#8203;">
  <!ENTITY RFC7416 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.7416.xml"> nbhy   "&#8209;">
  <!ENTITY RFC7668 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.7668.xml">
<!ENTITY RFC8174 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.8174.xml">
<!ENTITY RFC8505 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.8505.xml">
<!ENTITY RFC8928 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.8928.xml">
<!ENTITY I-D.ietf-6man-default-iids SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-6man-default-iids.xml"> wj     "&#8288;">
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<!-- used by XSLT processors -->
<!-- For a complete list and description of processing instructions (PIs),
    please see http://xml.resource.org/authoring/README.html. -->
<!-- Below are generally applicable Processing Instructions (PIs) that most I-Ds might want to use.
    (Here they are set differently than their defaults in xml2rfc v1.32) -->
<?rfc strict="no" ?>
<!-- give errors regarding ID-nits and DTD validation -->
<!-- control the table of contents (ToC) -->
<?rfc toc="yes"?>
<!-- generate a ToC -->
<?rfc tocdepth="4"?>
<!-- the number of levels of subsections in ToC. default: 3 -->
<!-- control references -->
<?rfc symrefs="yes"?>
<!-- use symbolic references tags, i.e, [RFC2119] instead of [1] -->
<?rfc sortrefs="yes" ?>
<!-- sort the reference entries alphabetically -->
<!-- control vertical white space
    (using these PIs as follows is recommended by the RFC Editor) -->
<?rfc compact="yes" ?>
<!-- do not start each main section on a new page -->
<?rfc subcompact="no" ?>
<!-- keep one blank line between list items -->
<!-- end of list of popular I-D processing instructions -->

<rfc category="std" xmlns:xi="http://www.w3.org/2001/XInclude" docName="draft-ietf-6lo-blemesh-10" ipr="trust200902">
 <!-- category values: std, bcp, info, exp, and historic
    ipr values: trust200902, noModificationTrust200902, noDerivativesTrust200902,
       or pre5378Trust200902
    you can add the attributes updates="NNNN" and obsoletes="NNNN"
    they will automatically be output with "(if approved)" --> number="9159" ipr="trust200902" obsoletes="" updates="" submissionType="IETF" category="std" consensus="true" xml:lang="en" tocInclude="true" tocDepth="4" symRefs="true" sortRefs="true" version="3">

  <!-- ***** FRONT MATTER ***** xml2rfc v2v3 conversion 3.9.1 -->
 <front>
   <!-- The abbreviated title is used in the page header - it is only necessary if the
        full title is longer than 39 characters -->

  <title abbrev="IPv6 mesh Mesh over Bluetooth LE">IPv6 Mesh over BLUETOOTH(R) Low Energy using IPSP</title> Using the Internet Protocol Support Profile (IPSP)</title>
    <seriesInfo name="RFC" value="9159"/>
    <author initials='C.G.' initials="C." surname="Gomez" fullname='Carles Gomez'> fullname="Carles Gomez">
      <organization abbrev="Universitat Politecnica de Catalunya">Universitat Politecnica de Catalunya</organization>
      <address>
        <postal>
          <street>C/Esteve Terradas, 7</street>
          <code>08860</code>
          <city>Castelldefels</city>
          <country>Spain</country>
        </postal>
        <email>carlesgo@entel.upc.edu</email>
      </address>
    </author>
    <author initials='S.M.D.' initials="S.M." surname="Darroudi" fullname='Seyed fullname="Seyed Mahdi Darroudi'> Darroudi">
      <organization abbrev="Universitat Politecnica de Catalunya">Universitat Politecnica de Catalunya</organization>
      <address>
        <postal>
          <street>C/Esteve Terradas, 7</street>
          <code>08860</code>
          <city>Castelldefels</city>
          <country>Spain</country>
        </postal>
        <email>sm.darroudi@entel.upc.edu</email>
      </address>
    </author>
    <author initials='T.S' initials="T." surname="Savolainen" fullname='Teemu Savolainen'> fullname="Teemu Savolainen">
      <organization abbrev="">Unaffiliated</organization>
      <address>
        <postal>
       <street></street>
       <city></city>
       <code></code>
       <country></country>
          <street/>
          <city/>
          <code/>
          <country/>
        </postal>
        <email>tsavo.stds@gmail.com</email>
      </address>
    </author>
    <author initials='M.S' initials="M." surname="Spoerk" fullname='Michael Spoerk'> fullname="Michael Spoerk">
      <organization abbrev="Graz University of Technology">Graz University of Technology</organization>
      <address>
        <postal>
          <street>Inffeldgasse 16/I</street>
          <city>Graz</city>
          <code>8010</code>
          <country>Austria</country>
        </postal>
        <email>michael.spoerk@tugraz.at</email>
      </address>
    </author>
    <date year="2021" month="November" />
    <area>Internet</area>
    <workgroup>6Lo Working Group</workgroup>
    <keyword>Bluetooth Low Energy</keyword>
    <keyword>mesh networks</keyword>
    <keyword>6lowpan</keyword>
    <keyword>IPv6</keyword>
    <keyword>Low power</keyword>
    <keyword>IoT</keyword>
    <keyword>Internet of Things</keyword>

    <abstract>
      <t>
         RFC 7668 describes the adaptation of 6LoWPAN IPv6 over Low-Power Wireless Personal Area Network (6LoWPAN) techniques to enable IPv6 over Bluetooth low energy Low Energy (Bluetooth LE) networks that follow the star topology.
         However, recent Bluetooth specifications allow the formation of extended topologies as well. This document specifies mechanisms that are needed
         to enable IPv6 mesh over Bluetooth Low Energy LE links established by using the Bluetooth Internet Protocol Support Profile. Profile (IPSP).
         This document does not specify the routing protocol to be used in an IPv6 mesh over Bluetooth LE links.
      </t>
    </abstract>
  </front>
  <middle>
    <section title="Introduction"> numbered="true" toc="default">
      <name>Introduction</name>
      <t>
        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], <xref target="IPSP" format="default"/> and <xref target="RFC7668">RFC target="RFC7668" format="default">RFC 7668</xref>, respectively.
   Bluetooth 4.0 only supports Bluetooth LE
   networks that follow the star topology.  As a consequence, <xref target="RFC7668">RFC target="RFC7668" format="default">RFC 7668</xref> was
   specifically developed and optimized for that type of network
   topology.  However, the functionality described in <xref target="RFC7668">RFC target="RFC7668" format="default">RFC 7668</xref> is not
   sufficient and would fail to enable an IPv6 mesh over Bluetooth LE links.  This
   document specifies mechanisms that are needed to enable IPv6 mesh over Bluetooth LE links.
   This document does not specify the routing protocol to be used in an
   IPv6 mesh over Bluetooth LE links.

      </t>
      <section title="Terminology numbered="true" toc="default">
        <name>Terminology and Requirements Language"> Language</name>
        <t>
    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
           "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
    NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
    "<bcp14>MAY</bcp14>", and "OPTIONAL" "<bcp14>OPTIONAL</bcp14>" in this document are to be interpreted as
    described in BCP14 BCP&nbsp;14 <xref target="RFC2119">RFC 2119</xref>, target="RFC2119"/> <xref target="RFC8174">RFC 8174</xref>, target="RFC8174"/>
    when, and only when, they appear in all capitals, as shown here.
        </t>

        <t>
	   The terms 6LoWPAN Node "6LoWPAN Node" (6LN), 6LoWPAN Router (6LR) "6LoWPAN Router" (6LR), and 6LoWPAN "6LoWPAN Border Router Router" (6LBR) are defined as in [RFC6775], <xref target="RFC6775" format="default"/>, with an addition that Bluetooth LE central and Bluetooth LE peripheral (see Section 2) <xref target="blue"/>) can both be adopted by a 6LN, a 6LR 6LR, or a 6LBR.
        </t>
      </section>
    </section>
    <section title="Bluetooth numbered="true" toc="default" anchor="blue">
      <name>Bluetooth LE Networks and the IPSP"> IPSP</name>
      <t>
        Bluetooth LE defines two Generic Access Profile (GAP) roles of relevance herein: the Bluetooth LE central role and the Bluetooth LE peripheral role.
        A
In Bluetooth 4.0, a device in the central role, which is called central "central" from now on, has traditionally been was able to manage multiple simultaneous connections with a number of devices in the peripheral role,
        called peripherals "peripherals" hereinafter. Bluetooth 4.1 (now deprecated) 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. network <xref target="BTCorev4.1"/>. In addition, a device may simultaneously
        be a central in a set of link layer link-layer connections, as well as a peripheral in others.
      </t>
      <t>
        On the other hand, the IPSP enables discovery of IP-enabled devices
        and the establishment of a link layer 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
   Consistent with Bluetooth 4.1 4.1, Bluetooth 4.2 <xref target="BTCorev4.2" format="default"/>, and subsequent Bluetooth
        versions (e.g. Bluetooth 4.2 [BTCorev4.2] or subsequent), versions, a device may implement both roles simultaneously.
      </t>
      <t>
        This document assumes a mesh network composed of Bluetooth LE links, where link layer link-layer
   connections are established between neighboring IPv6-enabled
   devices (see Section <xref target="three-b" format="none">Section 3.3.2, item 3.b, 3.b,</xref> and an example in Appendix A)). <xref target="Appendix"/>).  The IPv6 forwarding devices of the mesh have to implement both IPSP Node and Router roles, while simpler leaf-only nodes can implement only the Node role. In an IPv6 mesh over Bluetooth LE links, a node is a
   neighbor of another node, and vice versa, if a link layer link-layer connection
   has been established between both by using the IPSP functionality for
   discovery and link layer link-layer connection establishment for IPv6 packet
   transport.
      </t>
    </section>
    <section title="Specification numbered="true" toc="default" anchor="spec">
      <name>Specification of IPv6 mesh Mesh over Bluetooth LE links"> Links</name>
      <section title="Protocol stack"> numbered="true" toc="default">
        <name>Protocol Stack</name>
        <t>
 	      <xref target="fig_BLEMeshStack"/> target="fig_BLEMeshStack" format="default"/> illustrates the protocol stack for IPv6 mesh over Bluetooth LE
   links.  The core Bluetooth LE protocol stack comprises two main sections: the Controller, Controller and the Host. The former includes the Physical Layer, Layer
   and the Link Layer, whereas the latter is composed of the Logical Link Control and Adaptation Protocol (L2CAP), the Attribute Protocol (ATT),
   and the Generic Attribute Profile (GATT). The Host and the Controller sections are connected by means of the Host-Controller Interface (HCI).
   A device that supports the IPSP Node role instantiates one  Internet Protocol Support Service (IPSS), which runs atop GATT.
   The protocol stack shown in Figure 1 <xref target="fig_BLEMeshStack" format="default"/> shows two main differences with the IPv6 over
	Bluetooth LE stack in RFC 7668: a) the <xref target="RFC7668"/>:</t>
	<ol type="%c)">
	  <li>the adaptation layer below IPv6
   (labelled
	  (labeled as "6Lo for IPv6 mesh over Bluetooth LE") is now adapted for
	  IPv6 mesh over Bluetooth LE links, and b) the and</li>
	  <li>the protocol stack for IPv6
	  mesh over Bluetooth LE links includes IPv6 routing functionality. functionality.</li>
	</ol>

        <figure title="Protocol stack anchor="fig_BLEMeshStack">
          <name>Protocol Stack for IPv6 mesh Mesh over Bluetooth LE links."
                anchor="fig_BLEMeshStack">
        <artwork><![CDATA[ Links</name>
          <artwork name="" type="" align="left" alt=""><![CDATA[
                       +------------------------------------+
                       |             Application            |
          +---------+  +------------------------------------+
          |  IPSS   |  |            UDP/TCP/other           |
          +---------+  +------------------------------------+
          |  GATT   |  |             IPv6  |routing|        |
          +---------+  +------------------------------------+
          |  ATT    |  | 6Lo for IPv6 mesh over Bluetooh LE | Bluetooth LE|
          +---------+--+------------------------------------+
          |                 Bluetooth LE L2CAP              |
  HCI - - +-------------------------------------------------+ - -
          |               Bluetooth LE Link Layer           |
          +-------------------------------------------------+
          |             Bluetooth LE Physical Layer         |
          +-------------------------------------------------+
        ]]></artwork></figure>
        </t>
        ]]></artwork>
        </figure>
        <t>Bluetooth 4.2 defines a default MTU for Bluetooth LE of 251 bytes.  Excluding the L2CAP header of 4 bytes, a protocol data unit (PDU)
   size of 247 bytes is available for the layer above L2CAP. (Note: earlier Earlier Bluetooth LE versions offered a maximum amount of 23 bytes for the layer atop L2CAP.)
   The L2CAP provides a fragmentation and reassembly solution for transmitting or receiving larger PDUs. At each link, the IPSP defines means for
   negotiating a link-layer connection that provides an MTU of 1280 octets or higher for the IPv6 layer [IPSP]. <xref target="IPSP"/>.
   As per the present specification, the MTU size for IPv6 mesh over BLE links is 1280 octets.
        </t>
        <t>
            Similarly to RFC 7668, <xref target="RFC7668"/>, fragmentation functionality from 6LoWPAN standards is
   not used for IPv6 mesh over Bluetooth LE links. Bluetooth LE's fragmentation support provided
   by L2CAP is used.
        </t>
      </section>
      <section title="Subnet model" anchor="llroles"> anchor="llroles" numbered="true" toc="default">
        <name>Subnet Model</name>
        <t>
            For IPv6 mesh over Bluetooth LE links, a multilink model has been
   chosen, as further illustrated in Figure 2. <xref target="fig_SubnetModel"/>.  As IPv6 over Bluetooth
   LE is intended for constrained nodes, 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]. <xref target="RFC4903" format="default"/>.
   With the multilink subnet model, the routers have to take on the responsibility for of tracking the multicast state and forwarding
   multicast in a loop-free manner.
   Note that the route-over functionality defined in [RFC6775] <xref target="RFC6775" format="default"/>
   is essential to enable enabling the multilink subnet model for IPv6 mesh over Bluetooth LE links.

        </t>
        <figure title="Example anchor="fig_SubnetModel">
          <name>Example of an IPv6 mesh Mesh over a Bluetooth LE network connected Network Connected to the Internet"
         anchor="fig_SubnetModel">
         <artwork><![CDATA[ Internet</name>
          <artwork name="" type="" align="left" alt=""><![CDATA[
                                                       /
                                                      /
         6LR           6LN        6LN                /
            \             \          \              /
             \             \          \            /
    6LN ----- 6LR --------- 6LR ------ 6LBR ----- |  Internet
     <--Link--> <---Link--->/<--Link->/           |
                           /         /             \
               6LN ---- 6LR ----- 6LR               \
                                                     \
                                                      \

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

        ]]></artwork></figure>
        </t>
        ]]></artwork>
        </figure>
        <t>
        One or more 6LBRs are connected to the Internet. 6LNs are connected to the network through a 6LR or a 6LBR.
        Note that, that in some scenarios, scenarios and/or for some time intervals, a 6LR may remain at the edge of the network
        (e.g.
        (e.g., the top left node in Figure 2). <xref target="fig_SubnetModel"/>). This may happen when a 6LR has no neighboring 6LNs.
        A single Global Unicast global unicast prefix is used on the whole subnet.
        </t>
        <t>
        IPv6 mesh over Bluetooth LE links MUST <bcp14>MUST</bcp14> follow a route-over
   approach.  This document does not specify the routing protocol to be
   used in an IPv6 mesh over Bluetooth LE links.

        </t>
      </section>
      <section title="Link model" anchor="deviceaddressing"> anchor="deviceaddressing" numbered="true" toc="default">
        <name>Link Model</name>
        <section title="Stateless address autoconfiguration"> numbered="true" toc="default">
          <name>Stateless Address Autoconfiguration</name>
          <t>
        6LN, 6LR, and 6LBR IPv6 addresses in an IPv6 mesh over Bluetooth LE links are
   configured as per section 3.2.2 of RFC 7668. <xref target="RFC7668" sectionFormat="of" section="3.2.2"/>.

          </t>
          <t>
        Multihop Duplicate Address Detection (DAD) functionality as defined in section 8.2 of RFC 6775 <xref target="RFC6775" sectionFormat="of" section="8.2"/> and updated by RFC 8505, <xref target="RFC8505"/>, or some substitute mechanism (see section 3.3.2), MAY <xref target="btlemtu"/>), <bcp14>MAY</bcp14> be supported.
          </t>
        </section>
        <section title="Neighbor Discovery" anchor="btlemtu">
     <t>
        'Neighbor Discovery Optimization for IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs)' [RFC6775], anchor="btlemtu" numbered="true" toc="default">
          <name>Neighbor Discovery</name>
          <t>
"<xref target="RFC6775" format="title"/>" <xref target="RFC6775" format="default"/>, subsequently updated
         by 'Registration Extensions for IPv6 over Low-Power Wireless Personal Area Network (6LoWPAN) Neighbor Discovery' [RFC8505], "<xref target="RFC8505" format="title"/>" <xref target="RFC8505" format="default"/>,
         describes the neighbor discovery functionality adapted for use in several 6LoWPAN topologies, including the mesh topology.
         The route-over functionality of RFC 6775 <xref target="RFC6775"/> and RFC 8505 MUST <xref target="RFC8505"/> <bcp14>MUST</bcp14> be supported.
          </t>
          <t>
        The following aspects of the Neighbor Discovery optimizations for 6LoWPAN [RFC6775],[RFC8505] <xref target="RFC6775" format="default"/> <xref target="RFC8505" format="default"/> are applicable to Bluetooth LE 6LNs:
          </t>
     <t>
        1.
          <ol>
	    <li><t>
        A Bluetooth LE 6LN MUST <bcp14>MUST</bcp14> register its non-link-local addresses with
            its routers by sending a Neighbor Solicitation (NS) message with the Extended Address Registration Option (EARO) and process the
            Neighbor Advertisement (NA) accordingly.
            The EARO option includes a Registration Ownership Verifier (ROVR) field [RFC8505]. <xref target="RFC8505" format="default"/>.  In the case of Bluetooth LE, by default default, the ROVR field
            is filled with the 48-bit device address used by the Bluetooth LE node converted into 64-bit Modified EUI-64 format [RFC4291]. <xref target="RFC4291" format="default"/>.
            Optionally, a cryptographic ID (see <xref target="RFC8928">RFC target="RFC8928" format="default">RFC 8928</xref>) MAY <bcp14>MAY</bcp14> be placed in the ROVR field. If a cryptographic ID is used,
            address registration and multihop DAD formats and procedures defined in RFC 8928 MUST <xref target="RFC8928"/> <bcp14>MUST</bcp14> be used, used unless
            an alternative mechanism offering equivalent protection is used.
          </t>
          <t>
         As per RFC 8505, <xref target="RFC8505"/>, a 6LN link-local address does not need to be unique in the multilink subnet. A link-local address only needs to be unique
         from the perspective of the two nodes that use it to communicate (e.g., the 6LN and the 6LR in an NS/NA exchange). Therefore, the exchange
         of EDAR Extended Duplicate Address Request (EDAR) and EDAC Extended Duplicate Address Confirmation (EDAC) messages between the 6LR and a 6LBR, which ensures that an address is unique across the domain covered by the 6LBR, does not
         need to take place for link-local addresses.
          </t>
          <t>
     If the 6LN registers multiple addresses that are not based on the
   Bluetooth device address using the same compression context, the
   header compression efficiency may decrease, since only the last registered address can be fully elided (see Section 3.2.4 of RFC 7668).
     </t>

     <t>
     2. <xref target="RFC7668" sectionFormat="of" section="3.2.4"/>).
          </t></li>
          <li><t>
     For sending Router Solicitations and processing Router Advertisements, the hosts that participate in an IPv6 mesh over BLE MUST, <bcp14>MUST</bcp14>, respectively, follow Sections 5.3 <xref target="RFC6775" sectionFormat="bare" section="5.3"/> and 5.4 <xref target="RFC6775" sectionFormat="bare" section="5.4"/>
         of [RFC6775], <xref target="RFC6775" format="default"/>, and Section 5.6 of [RFC8505].
     </t>
     <t>
     3. <xref target="RFC8505" sectionFormat="of" section="5.6"/>.
          </t></li>
          <li><t>
     The router behavior for 6LRs and 6LBRs is described in Section 6 of RFC 6775, <xref target="RFC6775" sectionFormat="of" section="6"/> and updated by RFC 8505. <xref target="RFC8505"/>. However, as per this specification:

         a) Routers SHALL NOT
     </t><ol type="a">
         <li>Routers <bcp14>SHALL NOT</bcp14> use multicast NSs to discover other routers' link layer addresses.

         b) As link-layer addresses.</li>

        <li anchor="three-b">As per section 6.2 of RFC 6775, <xref target="RFC6775" sectionFormat="of" section="6.2"/>, in a dynamic configuration scenario, a 6LR comes up as a non-router and waits to receive a Router Advertisement
           for configuring its own interface address first, first before setting its interfaces to be advertising interfaces and turning into a router.
           In order to support such an operation in an IPv6 mesh over Bluetooth LE links, a 6LR first uses the IPSP Node role only. Once the 6LR has established
           a connection with another node currently running as a router, router and receives a Router Advertisement from that router, the 6LR configures its own
           interface address, it turns into a router, and it runs as an IPSP Router. In contrast with a 6LR, a 6LBR uses the IPSP Router role since the 6LBR
           is initialized, initialized; that is, the 6LBR uses both the IPSP Node and IPSP Router roles at all times.  See an example in Appendix B..
     </t>
     <t>
     4. <xref target="Appendix_B"/>.</li>
          </ol></li>
          <li><t>
     Border router behavior is described in Section 7 of RFC 6775, <xref target="RFC6775" sectionFormat="of" section="7"/> and updated by RFC 8505. <xref target="RFC8505"/>.
          </t>
          <t>
       RFC 6775
       <xref target="RFC6775"/> defines substitutable mechanisms for distributing prefixes and context information (section 8.1 of RFC 6775), (<xref target="RFC6775" sectionFormat="of" section="8.1"/>), as well as for
       Duplicate Address Detection
       duplicate address detection across a route-over 6LoWPAN (section 8.2 of RFC 6775). RFC 8505 (<xref target="RFC6775" sectionFormat="of" section="8.2"/>). <xref target="RFC8505"/> updates those mechanisms and the related message formats.
       Implementations of this specification MUST <bcp14>MUST</bcp14> either support the features described in sections 8.1 Sections <xref target="RFC6775" sectionFormat="bare" section="8.1"/> and 8.2 <xref target="RFC6775" sectionFormat="bare" section="8.2"/> of RFC 6775, <xref target="RFC6775"/>, as updated by RFC 8505, <xref target="RFC8505"/>
       or some alternative ("substitute") mechanism.
     </t>
          </t></li>
	</ol>
        </section>
        <section title="Header compression" anchor="hc"> anchor="hc" numbered="true" toc="default">
          <name>Header Compression</name>
          <t>
        Header compression as defined in RFC 6282 [RFC6282], <xref target="RFC6282" format="default"/>, which specifies the compression format for IPv6 datagrams on top of IEEE 802.15.4, is REQUIRED <bcp14>REQUIRED</bcp14> as the basis for IPv6 header compression on top of Bluetooth LE. All headers MUST <bcp14>MUST</bcp14> be compressed according to RFC 6282 [RFC6282] <xref target="RFC6282" format="default"/> encoding formats.
          </t>
          <t>
        To enable efficient header compression, when the 6LBR sends a Router Advertisement Advertisement, it MAY <bcp14>MAY</bcp14> include a 6LoWPAN Context Option (6CO) [RFC6775] <xref target="RFC6775" format="default"/>
        matching each address prefix advertised via a Prefix Information Option (PIO) [RFC4861] <xref target="RFC4861" format="default"/> for use in stateless address autoconfiguration.
        Note that 6CO is not needed for context-based compression when the context is pre-provisioned or provided by out-of-band means,
        as means
        as, in these cases cases, the in-band indication (6CO) becomes superfluous.

          </t>
          <t>
        The specific optimizations of RFC 7668 <xref target="RFC7668"/> for header compression, which
   exploited the star topology and ARO Address Registration Option (ARO) (note that the latter has been updated by EARO as per RFC 8505), <xref target="RFC8505"/>), cannot be generalized in an IPv6
   mesh over Bluetooth LE links.  Still, a subset of those optimizations
   can be applied in some cases in such a network.  These cases comprise link-local interactions, non-link-local packet
   transmissions originated by a 6LN (i.e. (i.e., the first hop from a 6LN), and non-link-local
   packets intended for a 6LN that are originated or forwarded by a neighbor
   of that 6LN (i.e. (i.e., the last hop toward a 6LN).  For all other packet transmissions, context-based compression MAY <bcp14>MAY</bcp14> be used.

          </t>
          <t>
        When a device transmits a packet to a neighbor, the sender MUST <bcp14>MUST</bcp14> fully elide the source IID Interface Identifier (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 <bcp14>MUST</bcp14> 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).
          </t>
          <t>
        When a 6LN transmits a packet, packet with a non-link-local source address
   that the 6LN has registered with EARO in the next-hop router for the
   indicated prefix, the source address MUST <bcp14>MUST</bcp14> 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, 6LN and the first 48 bits of the IID match
   with
   the latest address are registered by the 6LN, then the last 16 bits of the IID
   SHALL
   <bcp14>SHALL</bcp14> be carried in-line inline (SAC=1, SAM=10). Otherwise, if the first 48 bits of the IID do not match,
   then the 64 bits of the IID SHALL <bcp14>SHALL</bcp14> be fully carried in-line inline (SAC=1, SAM=01).

          </t>
          <t>
       When a router transmits a packet to a neighboring 6LN, 6LN with a non-
   link-local non-link-local destination address, the router MUST <bcp14>MUST</bcp14> fully elide the
   destination IPv6 address if the destination address is the latest
   registered by the 6LN with EARO for the indicated context (DAC=1,
   DAM=11).  If the destination address is a non-link-local address and
   not the latest registered, registered and if the first 48 bits of the IID match to those of the latest registered address,
   then the last 16 bits of the IID SHALL <bcp14>SHALL</bcp14> be carried in-line inline (DAC=1, DAM=10). Otherwise, if the first 48 bits of the IID do not match,
   then the 64 bits of the IID SHALL <bcp14>SHALL</bcp14> be fully carried in-line (DAC=1, DAM=01).
          </t>
        </section>
        <section title="Unicast numbered="true" toc="default">
          <name>Unicast and multicast mapping"> Multicast Mapping</name>
          <t>
     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 <bcp14>MUST</bcp14> keep track
   of neighboring multicast listeners, and it MUST NOT <bcp14>MUST NOT</bcp14> forward multicast
   packets to neighbors that have not registered as listeners for multicast groups to which the packets are destined.
          </t>
        </section>
      </section>
    </section>
    <section anchor="IANA" title="IANA Considerations"> numbered="true" toc="default">
      <name>IANA Considerations</name>
      <t>
      There are
      This document has no IANA considerations related to this document. actions.
      </t>
    </section>
    <section anchor="Security" title="Security Considerations"> numbered="true" toc="default">
      <name>Security Considerations</name>
      <t>
      The security considerations in RFC 7668 <xref target="RFC7668"/> apply.
      </t>

      <t>
     IPv6 mesh over Bluetooth LE links BLE requires a routing protocol to
   find end-to-end paths.  Unfortunately, the routing protocol may
   generate additional opportunities for threats and attacks to the
   network.

      </t>
      <t>
     <xref target="RFC7416">RFC target="RFC7416" format="default">RFC 7416</xref> 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.
      </t>
      <t>
     While this specification does not
   state the routing protocol to be used in IPv6 mesh over Bluetooth LE
   links, the guidance of RFC 7416 <xref target="RFC7416"/> is useful when RPL is used in
   such scenarios.  Furthermore, such guidance may partly apply for
   other routing protocols as well.
      </t>
      <t>
     The ROVR can be derived from the Bluetooth device address.  However, such a ROVR can be
   spoofed, and
   spoofed; therefore, any node connected to the subnet and aware of
   a registered-address-to-ROVR mapping could perform address theft and
   impersonation attacks. Use of Address Protected Neighbor Discovery <xref target="RFC8928">RFC 8928</xref> target="RFC8928" format="default"/> provides protection
   against such attacks.
      </t>
    </section>

<section anchor="Contrib" title="Contributors">
   <t>
      Carlo Alberto Boano (Graz University of Technology) contributed to the design and validation of this document.
   </t>
</section>

<section anchor="Acknowledgements" title="Acknowledgements">
   <t>
      The Bluetooth, Bluetooth Smart and Bluetooth Smart Ready marks are registered trademarks owned by Bluetooth SIG, Inc.
   </t>

   <t>
      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.
   </t>

   <t>
      The authors also thank Alain Michaud, Mark Powell, Martin Turon, Bilhanan Silverajan, Rahul Jadhav, Pascal Thubert, Acee Lindem, Catherine Meadows,
      and Dominique Barthel for their reviews and comments, which helped improve the document.
</t>

   <t>
      Carles Gomez has been supported in part by the Spanish Government Ministerio de Economia y Competitividad through projects TEC2012-32531,
      TEC2016-79988-P, PID2019-106808RA-I00 and FEDER, and Secretaria d'Universitats i Recerca del Departament d'Empresa i Coneixement de la Generalitat
      de Catalunya 2017 through grant SGR 376.
   </t>
</section>
  </middle>
  <back>

   <references>
      <name>References</name>
      <references>
        <name>Normative References</name>

        <reference anchor="IPSP" target="https://www.bluetooth.com/specifications/specs/internet-protocol-support-profile-1-0/">
          <front>
            <title>Internet Protocol Support Profile 1.0</title>
            <author>
              <organization>Bluetooth</organization>
            </author>
            <date year="2014" month="December" day="16"/>
          </front>
        </reference>

	<reference anchor="BTCorev4.2" target="https://www.bluetooth.com/specifications/specs/core-specification-4-2/">
          <front>
            <title>Core Specification 4.2</title>
            <author>
              <organization>Bluetooth</organization>
            </author>
            <date year="2014" month="December" day="2"/>
          </front>
        </reference>
	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4291.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4861.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6282.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6775.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7668.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8505.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8928.xml"/>
      </references>
      <references>
        <name>Informative References</name>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4903.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7416.xml"/>

        <reference anchor="BTCorev4.1" target="https://www.bluetooth.com/specifications/specs/core-specification-4-1/">
          <front>
            <title>Core Specification 4.1</title>
            <author>
              <organization>Bluetooth</organization>
            </author>
            <date year="2013" month="December" day="3"/>
          </front>
        </reference>
      </references>
    </references>

    <section anchor="Appendix" title="Appendix A: Bluetooth LE connection establishment example"> numbered="true" toc="default">
      <name>Bluetooth LE Connection Establishment Example</name>
   <t>
      This appendix provides an example of Bluetooth LE connection establishment and use of IPSP roles in an IPv6 mesh over Bluetooth LE links BLE that uses dynamic configuration. The example follows text in Section <xref target="three-b" format="none">Section 3.3.2, item 3.b). 3.b</xref>.
      </t>
      <t>
      The example assumes a network with one 6LBR, two 6LRs 6LRs, and three 6LNs, as shown in <xref target="fig_Appendix"/>. target="fig_Appendix" format="default"/>. Connectivity between the 6LNs and the 6LBR is only possible via the 6LRs.
      </t>
      <t>
      The following text describes the different steps as time evolves, in the example. example as time evolves. Note that other sequences of events that may lead to the same final scenario are also possible.
      </t>
      <t>
      At the beginning, the 6LBR starts running as an IPSP Router, router, whereas the rest of devices are not yet initialized (Step 1). (<xref target="step1" format="none">Step 1</xref>). Next, the 6LRs start running as IPSP Nodes, nodes, i.e., they use Bluetooth LE advertisement packets to announce their presence and support of IPv6 capabilities (Step 2). (<xref target="step2" format="none">Step 2</xref>).
      The 6LBR (already running as an IPSP Router) router) discovers the presence of the 6LRs and establishes one Bluetooth LE connection with each 6LR (Step 3). (<xref target="step3" format="none">Step 3</xref>). After establishment of those link layer link-layer connections (and after reception of Router Advertisements from the 6LBR),
      the 6LRs start operating as routers, routers and also initiate the IPSP Router role (Step 4) (note: (<xref target="step4" format="none">Step 4</xref>). (Note: whether the IPSP Node role is kept running simultaneously is an implementation decision). Then, 6LNs start running the IPSP Node role (Step 5). (<xref target="step5" format="none">Step 5</xref>).
      Finally, the 6LRs discover the presence of the 6LNs and establish connections with the latter (Step 6). (<xref target="step6" format="none">Step 6</xref>).
      </t>
      <figure title="An example anchor="fig_Appendix">
        <name>Example of connection establishment Connection Establishment and use Use of IPSP roles Roles in an IPv6 mesh Mesh over Bluetooth LE links."
                anchor="fig_Appendix">
        <artwork><![CDATA[ Links</name>
        <artwork anchor="step1" name="" type="" align="left" alt=""><![CDATA[
Step 1
******
                                     6LBR
                                (IPSP: Router)

                           6LR                 6LR
                   (not initialized)     (not initialized)

             6LN                 6LN                  6LN
    (not initialized)      (not initialized)     (not initialized)
]]></artwork>
<artwork anchor="step2" name="" type="" align="left" alt=""><![CDATA[
Step 2
******
                                     6LBR
                                (IPSP: Router)

                           6LR                 6LR
                      (IPSP: Node)         (IPSP: Node)

             6LN                 6LN                  6LN
    (not initialized)      (not initialized)     (not initialized)

]]></artwork>
<artwork anchor="step3" name="" type="" align="left" alt=""><![CDATA[
Step 3
******

                                     6LBR
                                (IPSP: Router)
  Bluetooth LE connection -->   /            \
                               /              \
                           6LR                 6LR
                      (IPSP: Node)         (IPSP: Node)

             6LN                 6LN                  6LN
    (not initialized)      (not initialized)     (not initialized)

]]></artwork>
<artwork anchor="step4" name="" type="" align="left" alt=""><![CDATA[
Step 4
******

                                     6LBR
                                (IPSP: Router)
	                        /            \
                               /              \
                           6LR                 6LR
                      (IPSP: Router)      (IPSP: Router)

             6LN                 6LN                  6LN
    (not initialized)      (not initialized)     (not initialized)
]]></artwork>
<artwork anchor="step5" name="" type="" align="left" alt=""><![CDATA[
Step 5
******

                                     6LBR
                                (IPSP: Router)
	                        /            \
                               /              \
                           6LR                 6LR
                      (IPSP: Router)      (IPSP: Router)

             6LN                   6LN                6LN
         (IPSP: Node)         (IPSP: Node)        (IPSP: Node)
]]></artwork>
<artwork anchor="step6" name="" type="" align="left" alt=""><![CDATA[
Step 6
******

                                     6LBR
                                (IPSP: Router)
	                        /            \
                               /              \
                           6LR                 6LR
                     (IPSP: Router)       (IPSP: Router)
                      /           \       /            \
                     /             \     /              \
                    /               \   /                \
                 6LN                 6LN                  6LN
            (IPSP: Node)         (IPSP: Node)         (IPSP: Node)

        ]]></artwork></figure>
        ]]></artwork>
      </figure>
    </section>
    <section anchor="Appendix_B" title="Appendix B: Node joining procedure"> numbered="true" toc="default">
      <name>Node-Joining Procedure</name>
      <t>
      This appendix provides a diagram that illustrates the node joining node-joining procedure. First of all, the joining node advertises its presence in order to allow establishing establishment of Bluetooth LE connections with neighbors that already belong to a network. The latter neighbors typically run as a 6LR or as a 6LBR. After Bluetooth LE connection establishment, the joining node starts acting as a 6LN.
      </t>
      <t><xref target="fig_AppendixB"/> target="fig_AppendixB" format="default"/> shows the sequence of messages that are exchanged by the 6LN and a neighboring 6LR that already belongs to the network, network after the establishment of a Bluetooth LE connection between both devices. Initially, the 6LN sends an RS a Router Solicitation (RS) message (1). Then, the 6LR replies
      with an RA, which includes the PIO (2). After discovering the non-link-local prefix in use in the network, the 6LN creates its non-link-local address, address and registers that address with EARO (3) in the 6LR, and then multihop DAD is performed (4).
      The next step is the transmission of the NA message sent by the 6LR in response to the NS previously sent by the 6LN (5).
      If the non-link-local address of the 6LN has been successfully validated, the 6LN can operate as a member of the network it has joined.
      </t>
      <figure title="Message exchange diagram anchor="fig_AppendixB">
        <name>Message Exchange Diagram for a joining node"
         anchor="fig_AppendixB">
         <artwork><![CDATA[ Joining Node</name>
        <artwork name="" type="" align="left" alt=""><![CDATA[
            (1)   		6LN ----(RS)-------> 6LR
            (2)   		6LN <---(RA-PIO)---- 6LR
            (3)   		6LN ----(NS-EARO)--> 6LR
            (4)	                [Multihop DAD procedure]
            (5)	          	6LN <---(NA)-------- 6LR

        ]]></artwork></figure>
        ]]></artwork>
      </figure>
    </section>

</middle>

 <back>
   <!-- References split into informative

    <section anchor="Acknowledgements" numbered="false" toc="default">
      <name>Acknowledgements</name>
      <t>
      The Bluetooth, Bluetooth Smart, and normative -->

   <!-- There Bluetooth Smart Ready marks are 2 ways registered trademarks owned by Bluetooth SIG, Inc.
      </t>
      <t>
      The authors of this document are grateful to insert reference entries all authors of <xref target="RFC7668"/>, since this document borrows many concepts (albeit with necessary extensions) from the citation libraries:
    1. define an ENTITY at the top, <xref target="RFC7668"/>.
      </t>
      <t>
      The authors also thank  <contact fullname="Alain Michaud"/>,  <contact fullname="Mark Powell"/>,  <contact fullname="Martin Turon"/>,  <contact fullname="Bilhanan Silverajan"/>,  <contact fullname="Rahul Jadhav"/>,  <contact fullname="Pascal Thubert"/>,  <contact fullname="Acee Lindem"/>,  <contact fullname="Catherine Meadows"/>,
      and  <contact fullname="Dominique Barthel"/> for their reviews and use "ampersand character"RFC2629; here (as shown)
    2. simply use a PI "less than character"?rfc include="reference.RFC.2119.xml"?> here
       (for I-Ds: include="reference.I-D.narten-iana-considerations-rfc2434bis.xml")

    Both are cited textually in the same manner: by using xref elements.
    If you use comments, which helped improve the PI option, xml2rfc will, by default, try to find included files document.
</t>
      <t>
       <contact fullname="Carles Gomez"/> has been supported in part by the same
    directory as the including file. You can also define the XML_LIBRARY environment variable
    with a value containing a set Spanish Government Ministerio de Economia y Competitividad through projects TEC2012-32531,
      TEC2016-79988-P, PID2019-106808RA-I00, and FEDER and Secretaria d'Universitats i Recerca del Departament d'Empresa i Coneixement de la Generalitat
      de Catalunya 2017 through grant SGR 376.
      </t>
    </section>
    <section anchor="Contrib" numbered="false" toc="default">
      <name>Contributors</name>
      <t>
      <contact fullname="Carlo Alberto Boano"/> (Graz University of directories Technology) contributed to search.  These can be either in the local
    filing system or remote ones accessed by http (http://domain/dir/... ).-->

   <references title="Normative References">
     <reference anchor="IPSP" target="https://www.bluetooth.org/en-us/specification/adopted-specifications">
        <front>
            <title>Bluetooth Internet Protocol Support Profile Specification Version 1.0.0</title>
            <author>
            <organization>Bluetooth Special Interest Group</organization>
            </author>
            <date year="2014" month="December" day="16"/>
        </front>
     </reference>
     <reference anchor="BTCorev4.2" target="https://www.bluetooth.com/specifications/archived-specifications">
        <front>
            <title>Bluetooth Core Specification Version 4.2</title>
            <author>
            <organization>Bluetooth Special Interest Group</organization>
            </author>
            <date year="2014" month="December" day="2"/>
        </front>
     </reference>

     <!--?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml"?-->
     &RFC2119;
     &RFC4291;
     &RFC4861;
     &RFC6282;
     &RFC6775;
     &RFC7668;
     &RFC8505;
     &RFC8174;
     &RFC8928;
   </references>

   <references title="Informative References">
     <!--?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml"?-->
     &RFC4903;
     &RFC7416;
     <reference anchor="BTCorev4.1" target="https://www.bluetooth.org/en-us/specification/adopted-specifications">
        <front>
            <title>Bluetooth Core Specification Version 4.1</title>
            <author>
            <organization>Bluetooth Special Interest Group</organization>
            </author>
            <date year="2013" month="December" day="3"/>
        </front>
     </reference>

   </references>

   <!-- Change Log
v00 2011-03-07  BPa  Initial version

     --> design and validation of this document.
      </t>
    </section>
  </back>
</rfc>