IEEE 802.15.4 Information Element encapsulation of 6TiSCH Join and Enrollment InformationUniversidad Diego PortalesEscuela de Informatica y Telecomunicaciones, Av. Ejercito 441Santiago, Region MetropolitanaChile+56 (2) 676-8121diego.dujovne@mail.udp.clSandelman Software Worksmcr+ietf@sandelman.ca
Internet
6tisch Working GroupInternet-DraftIn TSCH mode of IEEE STD 802.15.4, opportunities for broadcasts are limited to
specific times and specific channels. Nodes in a TSCH network typically
frequently send Enhanced Beacon (EB) frames to announce the presence of the
network. This document provides a mechanism by which small details critical
for new nodes (pledges) and long sleeping nodes may be carried within the Enhanced Beacon.Introduction describes the use of the time-slotted channel
hopping (TSCH) mode of . As further detailed in
, an Enhanced Beacon (EB) is transmitted during a slot
designated a broadcast slot.Use of BCP 14 TerminologyThe key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED",
"MAY", and "OPTIONAL" in this document are to be interpreted as
described in BCP 14 when, and only when, they
appear in all capitals, as shown here.Other terminology can be found in in section
2.1.Layer-2 SynchronizationAs explained in section 6 of , the Enhanced Beacon (EB)
has a number of purposes: synchronization of ASN and Join Metric, carrying timeslot
template identifier, carrying the channel hopping sequence identifier, and
indicating the TSCH SlotFrame.The EB is used by nodes already part of a TSCH network to
annouce its existence.
Receiving an EB allows a Joining Node (pledge) to learn about the network and
synchronize to it.
The EB may also be used as a means for a node already part of the network to
re-synchronize .There is a limited number of timeslots designated as a broadcast slot by each
router in the network. Considering 10ms slots and a slot-frame length of 100,
these slots are rare and could result in only 1 slot/s for a broadcast, which
needs to be used for the beacon. Additional broadcasts for Router
Advertisements, or Neighbor Discovery could even more scarce.Layer-3 synchronization: IPv6 Router Solicitations and AdvertisementsAt layer 3, defines a mechanism by which nodes learn about
routers by receiving multicast Router Advertisements (RA).
If no RA is heard within a set time, then a Router Solicitation (RS) may be
sent as multicast, to which an RA will be received, usually unicast.Although reduces the amount of multicast necessary to do address
resolution via Neighbor Solicitation (NS) messages, it still requires multicast
of either RAs or RS. This is an expensive operation for two reasons: First, there
are few multicast timeslots for unsolicited RAs; and second, if a pledge node does not
hear an RA, and decides to send a RS, a broadcast aloha slot is consumed with
unencrypted traffic. In this case, a unicast RS may be sent in response.This is a particularly acute issue for the join process for the following
reasons:
use of a multicast slot by even a non-malicious unauthenticated node for
a Router Solicitation (RS) may overwhelm that time slot.
it may require many seconds of on-time before a new pledge hears a Router
Advertisement (RA) that it can use.
a new pledge may listen to many Enhanced Beacons (EB) before it can pick an
appropriate network and/or closest Join Assistant to attach to. If it must
listen for a RA as well as find the Enhanced Beacon (EB), then the process may
take a very long time.
This document defines a new IETF IE subtype to provide join and enrollment information to prospective
pledges in a more efficient way.Protocol Definition creates a registry for new IETF IE subtypes.
This document allocates a new subtype.The new IE subtype structure is as follows. As explained in
the length of the Sub-Type Content can be calculated from the
container, so no length information is necessary.
R
the Router Advertisement R-flag is set if the sending node will act as a
Router for host-only nodes that need addressing via unicast Router
Solicitation messages.
P
if the Proxy Address P-flag is set, then the lower 64-bits of the Join Proxy's
link-local address follows the network ID. If the Proxy Address bit is not set,
then the Link Layer address of the Join Proxy is identical to the Layer-2 8-byte
address used to originate this enhanced beacon.
In either case, the destination layer-2 address of
this beacon may use the layer-2 address which was used to originate the beacon.
proxy priority (proxy prio)
this field indicates the willingness of the sender to act as join proxy.
Lower value indicates greater willingness to act as a Join Proxy as described in
. Values range 0x00 (most willing)
to 0x7e (least willing). A priority of 0x7f indicates that
the announcer should never be considered as a viable enrollment proxy. Only
unenrolled pledges look at this value.
rank priority
the rank "priority" is set by the 6LR which sent the beacon and is an
indication of how willing this 6LR is to serve as an RPL parent within a
particular network ID. This is a local value to be determined in other
work. It might be calculated from RPL rank, and it may include some
modifications based upon current number of children, or number of neighbor
cache entries available. This value MUST be ignored by pledges, it is for
enrolled devices only.
pan priority
the pan priority is a value set by the DODAG root to indicate the relative
priority of this LLN compared to those with different PANIDs. This value may
be used as part of the enrollment priority, but typically is used by devices
which have already enrolled, and need to determine which PAN to pick.
Unenrolled pledges MAY consider this value when selecting a PAN to join.
Enrolled devices MAY consider this value when looking for an eligible parent device.
Join Proxy lower-64
if the P bit is set, then 64 bits (8 bytes) of
address are present. This field provides the suffix of the Link-Local
address of the Join Proxy. The associated prefix is well-known as
fe80::/64.
network ID
this is a variable length field, up to 16-bytes in size that uniquely identifies
this network, potentially among many networks that are operating in the same
frequencies in overlapping physical space. The length of this field can be
calculated as being whatever is left in the Information Element.
In a 6tisch network, where RPL is used as the mesh routing protocol, the
network ID can be constructed from a SHA256 hash of the prefix (/64) of the
network. That is just a suggestion for a default value.
In some LLNs where multiple PANIDs may lead to the same management device
(the JRC), then a common value that is the same across all PANs MUST be configured.Security ConsiderationsAll of the contents of this Information Element are sent in the clear.
The containing Enhanced Beacon is not encrypted.
This is a restriction in the cryptographic architecture of the TSCH
mechanism.
In order to decrypt or do integrity checking of layer-2 frames in TSCH, the
TSCH Absolute Slot Number (ASN) is needed.
The Enhanced Beacon provides the ASN to new (and long-sleeping) nodes.The Enhanced Beagon is authenticated at the layer-2 level using 802.15.4
mechanisms using the network-wide keying material. Nodes which are enrolled
will have the network-wide keying material and can validate the beacon,
providing them with a trustedPledges which have not yet enrolled are unable to authenticate the beacons,
and will be forced to temporarily take the contents on faith.
After enrollment, a newly enrolled node will be able to return to the beacon and
validate it.In addition to the enrollment and join information described in this
document, the Enhanced Beacon contains a description of the TSCH schedule to
be used by the transmitter of this packet.
The schedule can provide an attacker with a list of channels and frequencies
on which communication will occur.
Knowledge of this can help an attacker to more efficiently jam
communications, although there is future work being considered to make some
of the schedule less visible.Privacy ConsiderationsThe use of a network ID may reveal information about the network. The use of
a SHA256 hash of the DODAGID, rather than using the DODAGID directly provides
some cover the addresses used within the network. The DODAGID is usually the
IPv6 address of the root of the RPL mesh.An interloper with a radio sniffer would be able to use the network ID to map
out the extent of the mesh network.IANA ConsiderationsAllocate a new number TBD-XXX from Registry IETF IE Sub-type ID, as defined by .
This entry should be called 6tisch-Join-Info, and should refer to this document.AcknowledgementsThomas Watteyne provided extensive editorial comments on the document.
Carles Gomez Montenegro generated a detailed review of the document at WGLC.
Tim Evens provided a number of useful editorial suggestions.ReferencesNormative ReferencesKey words for use in RFCs to Indicate Requirement LevelsIn many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.Ambiguity of Uppercase vs Lowercase in RFC 2119 Key WordsRFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings.IEEE 802.15.4 Information Element for the IETFIEEE Std 802.15.4 defines Information Elements (IEs) that can be used to extend 802.15.4 in an interoperable manner. The IEEE 802.15 Assigned Numbers Authority (ANA) manages the registry of the Information Elements. This document formulates a request for ANA to allocate a number from that registry for the IETF and describes how the IE is formatted to provide subtypes.Neighbor Discovery Optimization for IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs)The IETF work in IPv6 over Low-power Wireless Personal Area Network (6LoWPAN) defines 6LoWPANs such as IEEE 802.15.4. This and other similar link technologies have limited or no usage of multicast signaling due to energy conservation. In addition, the wireless network may not strictly follow the traditional concept of IP subnets and IP links. IPv6 Neighbor Discovery was not designed for non- transitive wireless links, as its reliance on the traditional IPv6 link concept and its heavy use of multicast make it inefficient and sometimes impractical in a low-power and lossy network. This document describes simple optimizations to IPv6 Neighbor Discovery, its addressing mechanisms, and duplicate address detection for Low- power Wireless Personal Area Networks and similar networks. The document thus updates RFC 4944 to specify the use of the optimizations defined here. [STANDARDS-TRACK]Neighbor Discovery for IP version 6 (IPv6)This document specifies the Neighbor Discovery protocol for IP Version 6. IPv6 nodes on the same link use Neighbor Discovery to discover each other's presence, to determine each other's link-layer addresses, to find routers, and to maintain reachability information about the paths to active neighbors. [STANDARDS-TRACK]Constrained Join Protocol (CoJP) for 6TiSCHThis document describes the minimal framework required for a new device, called "pledge", to securely join a 6TiSCH (IPv6 over the TSCH mode of IEEE 802.15.4e) network. The framework requires that the pledge and the JRC (join registrar/coordinator, a central entity), share a symmetric key. How this key is provisioned is out of scope of this document. Through a single CoAP (Constrained Application Protocol) request-response exchange secured by OSCORE (Object Security for Constrained RESTful Environments), the pledge requests admission into the network and the JRC configures it with link-layer keying material and other parameters. The JRC may at any time update the parameters through another request-response exchange secured by OSCORE. This specification defines the Constrained Join Protocol and its CBOR (Concise Binary Object Representation) data structures, and describes how to configure the rest of the 6TiSCH communication stack for this join process to occur in a secure manner. Additional security mechanisms may be added on top of this minimal framework.IEEE Std. 802.15.4, Part. 15.4: Wireless Medium Access Control (MAC) and Physical Layer (PHY) Specifications for Low-Rate Wireless Personal Area NetworksAmbiguity of Uppercase vs Lowercase in RFC 2119 Key WordsRFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings.Informative ReferencesAn Architecture for IPv6 over the TSCH mode of IEEE 802.15.4This document describes a network architecture that provides low- latency, low-jitter and high-reliability packet delivery. It combines a high-speed powered backbone and subnetworks using IEEE 802.15.4 time-slotted channel hopping (TSCH) to meet the requirements of LowPower wireless deterministic applications.Minimal IPv6 over the TSCH Mode of IEEE 802.15.4e (6TiSCH) ConfigurationThis document describes a minimal mode of operation for an IPv6 over the TSCH mode of IEEE 802.15.4e (6TiSCH) network. This minimal mode of operation specifies the baseline set of protocols that need to be supported and the recommended configurations and modes of operation sufficient to enable a 6TiSCH functional network. 6TiSCH provides IPv6 connectivity over a Time-Slotted Channel Hopping (TSCH) mesh composed of IEEE Std 802.15.4 TSCH links. This minimal mode uses a collection of protocols with the respective configurations, including the IPv6 Low-Power Wireless Personal Area Network (6LoWPAN) framework, enabling interoperable IPv6 connectivity over IEEE Std 802.15.4 TSCH. This minimal configuration provides the necessary bandwidth for network and security bootstrapping and defines the proper link between the IETF protocols that interface to IEEE Std 802.15.4 TSCH. This minimal mode of operation should be implemented by all 6TiSCH-compliant devices.RPL: IPv6 Routing Protocol for Low-Power and Lossy NetworksLow-Power and Lossy Networks (LLNs) are a class of network in which both the routers and their interconnect are constrained. LLN routers typically operate with constraints on processing power, memory, and energy (battery power). Their interconnects are characterized by high loss rates, low data rates, and instability. LLNs are comprised of anything from a few dozen to thousands of routers. Supported traffic flows include point-to-point (between devices inside the LLN), point-to-multipoint (from a central control point to a subset of devices inside the LLN), and multipoint-to-point (from devices inside the LLN towards a central control point). This document specifies the IPv6 Routing Protocol for Low-Power and Lossy Networks (RPL), which provides a mechanism whereby multipoint-to-point traffic from devices inside the LLN towards a central control point as well as point-to-multipoint traffic from the central control point to the devices inside the LLN are supported. Support for point-to-point traffic is also available. [STANDARDS-TRACK]Using IEEE 802.15.4e Time-Slotted Channel Hopping (TSCH) in the Internet of Things (IoT): Problem StatementThis document describes the environment, problem statement, and goals for using the Time-Slotted Channel Hopping (TSCH) Medium Access Control (MAC) protocol of IEEE 802.14.4e in the context of Low-Power and Lossy Networks (LLNs). The set of goals enumerated in this document form an initial set only.