draft-ietf-6lo-blemesh-06.txt   draft-ietf-6lo-blemesh-07.txt 
6Lo Working Group C. Gomez 6Lo Working Group C. Gomez
Internet-Draft S. Darroudi Internet-Draft S. Darroudi
Intended status: Standards Track Universitat Politecnica de Catalunya Intended status: Standards Track Universitat Politecnica de Catalunya
Expires: March 31, 2020 T. Savolainen Expires: June 16, 2020 T. Savolainen
DarkMatter DarkMatter
M. Spoerk M. Spoerk
Graz University of Technology Graz University of Technology
September 28, 2019 December 14, 2019
IPv6 Mesh over BLUETOOTH(R) Low Energy using IPSP IPv6 Mesh over BLUETOOTH(R) Low Energy using IPSP
draft-ietf-6lo-blemesh-06 draft-ietf-6lo-blemesh-07
Abstract Abstract
RFC 7668 describes the adaptation of 6LoWPAN techniques to enable RFC 7668 describes the adaptation of 6LoWPAN techniques to enable
IPv6 over Bluetooth low energy networks that follow the star IPv6 over Bluetooth low energy networks that follow the star
topology. However, recent Bluetooth specifications allow the topology. However, recent Bluetooth specifications allow the
formation of extended topologies as well. This document specifies formation of extended topologies as well. This document specifies
mechanisms that are needed to enable IPv6 mesh over Bluetooth Low mechanisms that are needed to enable IPv6 mesh over Bluetooth Low
Energy links established by using the Bluetooth Internet Protocol Energy links established by using the Bluetooth Internet Protocol
Support Profile. This document does not specify the routing protocol Support Profile. This document does not specify the routing protocol
skipping to change at page 1, line 41 skipping to change at page 1, line 41
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 https://datatracker.ietf.org/drafts/current/. Drafts is at https://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 March 31, 2020. This Internet-Draft will expire on June 16, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2019 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
(https://trustee.ietf.org/license-info) in effect on the date of (https://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
1.1. Terminology and Requirements Language . . . . . . . . . . 3 1.1. Terminology and Requirements Language . . . . . . . . . . 3
2. Bluetooth LE Networks and the IPSP . . . . . . . . . . . . . 3 2. Bluetooth LE Networks and the IPSP . . . . . . . . . . . . . 3
3. Specification of IPv6 mesh over Bluetooth LE links . . . . . 4 3. Specification of IPv6 mesh over Bluetooth LE links . . . . . 4
3.1. Protocol stack . . . . . . . . . . . . . . . . . . . . . 4 3.1. Protocol stack . . . . . . . . . . . . . . . . . . . . . 4
3.2. Subnet model . . . . . . . . . . . . . . . . . . . . . . 5 3.2. Subnet model . . . . . . . . . . . . . . . . . . . . . . 5
3.3. Link model . . . . . . . . . . . . . . . . . . . . . . . 6 3.3. Link model . . . . . . . . . . . . . . . . . . . . . . . 6
3.3.1. Stateless address autoconfiguration . . . . . . . . . 6 3.3.1. Stateless address autoconfiguration . . . . . . . . . 6
3.3.2. Neighbor Discovery . . . . . . . . . . . . . . . . . 6 3.3.2. Neighbor Discovery . . . . . . . . . . . . . . . . . 6
3.3.3. Header compression . . . . . . . . . . . . . . . . . 7 3.3.3. Header compression . . . . . . . . . . . . . . . . . 7
3.3.4. Unicast and multicast mapping . . . . . . . . . . . . 8 3.3.4. Unicast and multicast mapping . . . . . . . . . . . . 8
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
5. Security Considerations . . . . . . . . . . . . . . . . . . . 9 5. Security Considerations . . . . . . . . . . . . . . . . . . . 9
6. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 9 6. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 9
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9
8. Appendix A: Bluetooth LE connection establishment example . . 10 8. Appendix A: Bluetooth LE connection establishment example . . 10
9. Appendix B: Node joining procedure . . . . . . . . . . . . . 13 9. Appendix B: Node joining procedure . . . . . . . . . . . . . 12
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 13
10.1. Normative References . . . . . . . . . . . . . . . . . . 13 10.1. Normative References . . . . . . . . . . . . . . . . . . 13
10.2. Informative References . . . . . . . . . . . . . . . . . 14 10.2. Informative References . . . . . . . . . . . . . . . . . 14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15
1. Introduction 1. Introduction
Bluetooth Low Energy (hereinafter, Bluetooth LE) was first introduced Bluetooth Low Energy (hereinafter, Bluetooth LE) was first introduced
in the Bluetooth 4.0 specification. Bluetooth LE (which has been in the Bluetooth 4.0 specification. Bluetooth LE (which has been
marketed as Bluetooth Smart) is a low-power wireless technology marketed as Bluetooth Smart) is a low-power wireless technology
skipping to change at page 3, line 45 skipping to change at page 3, line 45
establishment of a link layer connection for transporting IPv6 establishment of a link layer connection for transporting IPv6
packets. The IPSP defines the Node and Router roles for devices that packets. The IPSP defines the Node and Router roles for devices that
consume/originate IPv6 packets and for devices that can route IPv6 consume/originate IPv6 packets and for devices that can route IPv6
packets, respectively. Consistently with Bluetooth 4.1 and packets, respectively. Consistently with Bluetooth 4.1 and
subsequent Bluetooth versions (e.g. Bluetooth 4.2 [BTCorev4.2] or subsequent Bluetooth versions (e.g. Bluetooth 4.2 [BTCorev4.2] or
subsequent), a device may implement both roles simultaneously. subsequent), a device may implement both roles simultaneously.
This document assumes a mesh network composed of Bluetooth LE links, This document assumes a mesh network composed of Bluetooth LE links,
where link layer connections are established between neighboring where link layer connections are established between neighboring
IPv6-enabled devices (see Section 3.3.2, item 3.b)). The IPv6 IPv6-enabled devices (see Section 3.3.2, item 3.b)). The IPv6
forwarding devices of the mesh have to implement both Node and Router forwarding devices of the mesh have to implement both IPSP Node and
roles, while simpler leaf-only nodes can implement only the Node Router roles, while simpler leaf-only nodes can implement only the
role. In an IPv6 mesh over Bluetooth LE links, a node is a neighbor Node role. In an IPv6 mesh over Bluetooth LE links, a node is a
of another node, and vice versa, if a link layer connection has been neighbor of another node, and vice versa, if a link layer connection
established between both by using the IPSP functionality for has been established between both by using the IPSP functionality for
discovery and link layer connection establishment for IPv6 packet discovery and link layer connection establishment for IPv6 packet
transport. transport.
3. Specification of IPv6 mesh over Bluetooth LE links 3. Specification of IPv6 mesh over Bluetooth LE links
3.1. Protocol stack 3.1. Protocol stack
Figure 1 illustrates the protocol stack for IPv6 mesh over Bluetooth Figure 1 illustrates the protocol stack for IPv6 mesh over Bluetooth
LE links. There are two main differences with the IPv6 over LE links. There are two main differences with the IPv6 over
Bluetooth LE stack in RFC 7668: a) the adaptation layer below IPv6 Bluetooth LE stack in RFC 7668: a) the adaptation layer below IPv6
skipping to change at page 6, line 14 skipping to change at page 6, line 14
3.3. Link model 3.3. Link model
3.3.1. Stateless address autoconfiguration 3.3.1. Stateless address autoconfiguration
6LN, 6LR and 6LBR IPv6 addresses in an IPv6 mesh over Bluetooth LE 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. links are configured as per section 3.2.2 of RFC 7668.
Multihop DAD functionality as defined in section 8.2 of RFC 6775 and Multihop DAD functionality as defined in section 8.2 of RFC 6775 and
updated by RFC 8505, or some substitute mechanism (see section updated by RFC 8505, or some substitute mechanism (see section
3.3.2), MUST be supported. 3.3.2), MAY be supported.
3.3.2. Neighbor Discovery 3.3.2. Neighbor Discovery
'Neighbor Discovery Optimization for IPv6 over Low-Power Wireless 'Neighbor Discovery Optimization for IPv6 over Low-Power Wireless
Personal Area Networks (6LoWPANs)' [RFC6775], subsequently updated by Personal Area Networks (6LoWPANs)' [RFC6775], subsequently updated by
'Registration Extensions for IPv6 over Low-Power Wireless Personal 'Registration Extensions for IPv6 over Low-Power Wireless Personal
Area Network (6LoWPAN) Neighbor Discovery' [RFC8505], describes the Area Network (6LoWPAN) Neighbor Discovery' [RFC8505], describes the
neighbor discovery functionality adapted for use in several 6LoWPAN neighbor discovery functionality adapted for use in several 6LoWPAN
topologies, including the mesh topology. The route-over topologies, including the mesh topology. The route-over
functionality of RFC 6775 and RFC 8505 MUST be supported. functionality of RFC 6775 and RFC 8505 MUST be supported.
The following aspects of the Neighbor Discovery optimizations for The following aspects of the Neighbor Discovery optimizations for
6LoWPAN [RFC6775],[RFC8505] are applicable to Bluetooth LE 6LNs: 6LoWPAN [RFC6775],[RFC8505] are applicable to Bluetooth LE 6LNs:
1. A Bluetooth LE host MUST register its non-link-local addresses 1. A Bluetooth LE 6LN SHOULD register its non-link-local addresses
with its routers by sending a Neighbor Solicitation (NS) message with with its routers by sending a Neighbor Solicitation (NS) message with
the Extended Address Registration Option (EARO) and process the the Extended Address Registration Option (EARO) and process the
Neighbor Advertisement (NA) accordingly. The NS with the EARO option Neighbor Advertisement (NA) accordingly. Note that in some cases
MUST be sent irrespective of the method used to generate the IID. (e.g. very short-lived connections) it may not be worthwhile for a
The EARO option includes a Registration Ownership Verifier (ROVR) 6LN to send an NS with EARO for registering its address. The EARO
field [RFC8505]. In the case of Bluetooth LE, by default the ROVR option includes a Registration Ownership Verifier (ROVR) field
field is filled with the 48-bit device address used by the Bluetooth [RFC8505]. In the case of Bluetooth LE, by default the ROVR field is
LE node converted into 64-bit Modified EUI-64 format [RFC4291]. filled with the 48-bit device address used by the Bluetooth LE node
Optionally, a cryptographic ID (see [I-D.ietf-6lo-ap-nd] MAY be converted into 64-bit Modified EUI-64 format [RFC4291]. Optionally,
placed in the ROVR field. If a cryptographic ID is used, address a cryptographic ID (see [I-D.ietf-6lo-ap-nd] MAY be placed in the
registration and multihop DAD formats and procedures defined in ROVR field. If a cryptographic ID is used, address registration and
[I-D.ietf-6lo-ap-nd] MUST be used, unless an alternative mechanism multihop DAD formats and procedures defined in [I-D.ietf-6lo-ap-nd]
offering equivalent protection is used. As per RFC 8505, a 6LN MUST MUST be used, unless an alternative mechanism offering equivalent
NOT register its link-local address. protection is used. As per RFC 8505, a 6LN MUST NOT register its
link-local address.
If the 6LN registers for a same compression context multiple If the 6LN registers for a same compression context multiple
addresses that are not based on Bluetooth device address, the header addresses that are not based on Bluetooth device address, the header
compression efficiency will decrease. compression efficiency will decrease.
2. For sending Router Solicitations and processing Router 2. For sending Router Solicitations and processing Router
Advertisements the Bluetooth LE hosts MUST, respectively, follow Advertisements the Bluetooth LE hosts MUST, respectively, follow
Sections 5.3 and 5.4 of [RFC6775], and Section 5.6 of [RFC8505]. Sections 5.3 and 5.4 of [RFC6775], and Section 5.6 of [RFC8505].
3. The router behavior for 6LRs and 6LBRs is described in Section 6 3. The router behavior for 6LRs and 6LBRs is described in Section 6
skipping to change at page 7, line 28 skipping to change at page 7, line 28
IPSP Router. A 6LBR uses the IPSP Router role since the 6LBR is IPSP Router. A 6LBR uses the IPSP Router role since the 6LBR is
initialized. See an example in the Appendix. initialized. See an example in the Appendix.
4. Border router behavior is described in Section 7 of RFC 6775, and 4. Border router behavior is described in Section 7 of RFC 6775, and
updated by RFC 8505. updated by RFC 8505.
RFC 6775 defines substitutable mechanisms for distributing prefixes RFC 6775 defines substitutable mechanisms for distributing prefixes
and context information (section 8.1 of RFC 6775), as well as for and context information (section 8.1 of RFC 6775), as well as for
Duplicate Address Detection across a route-over 6LoWPAN (section 8.2 Duplicate Address Detection across a route-over 6LoWPAN (section 8.2
of RFC 6775). RFC 8505 updates those mechanisms and the related of RFC 6775). RFC 8505 updates those mechanisms and the related
message formats. Implementations of this specification MUST support message formats. Implementations of this specification MAY support
the features described in sections 8.1 and 8.2 of RFC 6775, as the features described in sections 8.1 and 8.2 of RFC 6775, as
updated by RFC 8505, unless some alternative ("substitute") from some updated by RFC 8505, unless some alternative ("substitute") from some
other specification is supported by the implementation. other specification is supported by the implementation.
3.3.3. Header compression 3.3.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 as the basis for IPv6 header compression on top of Bluetooth REQUIRED as the basis for IPv6 header compression on top of Bluetooth
LE. All headers MUST be compressed according to RFC 6282 [RFC6282] LE. All headers MUST be compressed according to RFC 6282 [RFC6282]
skipping to change at page 8, line 5 skipping to change at page 8, line 5
Option (PIO) [RFC4861] for use in stateless address Option (PIO) [RFC4861] for use in stateless address
autoconfiguration. Note that 6CO is not needed for context-based autoconfiguration. Note that 6CO is not needed for context-based
compression when a single prefix is used in the network. compression when a single prefix is used in the network.
The specific optimizations of RFC 7668 for header compression, which The specific optimizations of RFC 7668 for header compression, which
exploited the star topology and ARO (note that the latter has been exploited the star topology and ARO (note that the latter has been
updated by EARO as per RFC 8505), cannot be generalized in an IPv6 updated by EARO as per RFC 8505), cannot be generalized in an IPv6
mesh over Bluetooth LE links. Still, a subset of those optimizations mesh over Bluetooth LE links. Still, a subset of those optimizations
can be applied in some cases in such a network. These cases comprise can be applied in some cases in such a network. These cases comprise
link-local interactions, non-link-local packet transmissions link-local interactions, non-link-local packet transmissions
originated and performed by a 6LN, and non-link-local packets originated by a 6LN, and non-link-local packets intended for a 6LN
intended for a 6LN that are originated or forwarded by a neighbor of that are originated or forwarded by a neighbor of that 6LN. For the
that 6LN. For the rest of packet transmissions, context- based rest of packet transmissions, context-based compression MAY be used.
compression MAY be used.
When a device transmits a packet to a neighbor, the sender MUST fully 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 elide the source IID if the source IPv6 address is the link-local
address based on the sender's Bluetooth device address (SAC=0, address based on the sender's Bluetooth device address (SAC=0,
SAM=11). The sender also MUST fully elide the destination IPv6 SAM=11). The sender also MUST fully elide the destination IPv6
address if it is the link-local address based on the neighbor's address if it is the link-local address based on the neighbor's
Bluetooth device address (DAC=0, DAM=11). Bluetooth device address (DAC=0, DAM=11).
A 6LN SHOULD register its non-link-local address with EARO in the When a 6LN transmits a packet, with a non-link-local source address
next-hop router. Note that in some cases (e.g. very short-lived that the 6LN has registered with EARO in the next-hop router for the
connections) it may not be worthwhile for a 6LN to send an NS with indicated prefix, the source address MUST be fully elided if it is
EARO for registering its address. When a 6LN transmits a packet, the latest address that the 6LN has registered for the indicated
with a non-link-local source address that the 6LN has registered with prefix (SAC=1, SAM=11). If the source non-link-local address is not
EARO in the next-hop router for the indicated prefix, the source the latest registered by the 6LN, then the 64 bits of the IID SHALL
address MUST be fully elided if it is the latest address that the 6LN be fully carried in-line (SAC=1, SAM=01) or if the first 48 bits of
has registered for the indicated prefix (SAC=1, SAM=11). If the the IID match with the latest address registered by the 6LN, then the
source non-link-local address is not the latest registered by the last 16 bits of the IID SHALL be carried in-line (SAC=1, SAM=10).
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- When a router transmits a packet to a neighboring 6LN, with a non-
link-local destination address, the router MUST fully elide the link-local destination address, the router MUST fully elide the
destination IPv6 address if the destination address is the latest destination IPv6 address if the destination address is the latest
registered by the 6LN with EARO for the indicated context (DAC=1, 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 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 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 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). to the latest registered address, then elide those 48 bits (DAM=10).
 End of changes. 13 change blocks. 
43 lines changed or deleted 39 lines changed or added

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