rfc-9032

Encapsulation of 6TiSCH Join and Enrollment Information Elements

D. Dujovne (Editor), M. Richardson
date2021-05 streamIETF areaint wg6tisch statusPROPOSED STANDARD pages10 canonicalhttps://www.rfc-editor.org/rfc/rfc9032 doi10.17487/RFC9032
In the Time-Slotted Channel Hopping (TSCH) mode of IEEE Std 802.15.4, opportunities for broadcasts are limited to specific times and specific channels. Routers in a TSCH network transmit Enhanced Beacon (EB) frames to announce the presence of the network. This document provides a mechanism by which additional information critical for new nodes (pledges) and long-sleeping nodes may be carried within the EB in order to conserve use of broadcast opportunities.

Extracted elements (24)

design-rationale §2

The Join Proxy Interface ID field eliminates a separate service-discovery round-trip for cases where the Join Proxy's Layer 3 address cannot be derived from its Layer 2 address via SLAAC, reducing latency during the join process.

ip

design-rationale §1.3

The mechanism embeds join and enrollment information directly in the Enhanced Beacon rather than requiring separate broadcast messages, because broadcast slots in TSCH are extremely scarce (potentially only 1 per second) and additional multicasts for RA/RS would consume valuable Aloha slots with unencrypted traffic, severely slowing the pledge join process.

ip

design-rationale §1.4

The network ID field is introduced to allow pledges and enrolled devices to identify which PANs belong to the same backbone network, enabling informed PAN selection and avoiding redundant enrollment attempts when multiple PANIDs share the same JRC.

ip

interoperability-note §2

The length of the network ID field is implicitly determined by whatever bytes remain in the IE after preceding fixed-length fields, relying on the container length calculation defined in RFC 8137 rather than an explicit length subfield.

ip

normative-requirement §2 MUST

Host-only nodes relying on SLAAC (when the R flag is set) MUST send a unicast RS message in order to receive an RA with the Prefix Information Option.

ip

normative-requirement §2 MUST

Pledges MUST ignore the rank priority field; it is only useful for enrolled devices comparing connection points.

ip

normative-requirement §2 MUST

Reserved bits in the IE subtype MUST be ignored upon receipt and SHOULD be set to 0 when sending.

ip

normative-requirement §2 MAY

Unenrolled pledges MAY consider the PAN priority value when selecting a PAN to join; enrolled devices MAY consider it when looking for an eligible parent device.

ip

normative-requirement §2 MUST

When multiple PANIDs lead to the same JRC, a common network ID that is the same across all PANs MUST be configured, so pledges do not waste time attempting to enroll multiple times with the same network.

ip

privacy-consideration §4

An interloper with a radio sniffer can use the network ID to map the physical extent of the mesh network, correlating the same network ID observed across multiple EB transmissions.

privacy

privacy-consideration §4

Using a SHA-256 hash of the DODAGID (typically the IPv6 address of the RPL mesh root) for the network ID provides some privacy compared to using the DODAGID directly, as it does not directly reveal addresses used within the network.

privacy

protocol-element §2

Defines a new IETF IE subtype (value 2, '6tisch-Join-Info') to be placed in IEEE 802.15.4 Enhanced Beacon (EB) frames, carrying join and enrollment information for pledges and long-sleeping nodes. The subtype includes fields: R flag, P flag, reserved bits, proxy priority, rank priority, PAN priority, optional Join Proxy Interface ID, and variable-length network ID.

ip, registry

protocol-element §2

The Join Proxy Interface ID field (64 bits, present if P=1) provides the IID of the link-local address of the Join Proxy, with the well-known prefix fe80::/64. If absent, the IID is derived from the Layer 2 address per SLAAC (RFC 4862).

ip

protocol-element §2

The network ID field is variable length, up to 16 bytes, uniquely identifying the network among potentially overlapping networks. Its length is whatever remains in the IE after preceding fields. In 6TiSCH/RPL networks, it may be a truncated SHA-256 hash of the network prefix (/64).

ip

protocol-element §2

The PAN priority field (8 bits) is set by the DODAG root (6LBR) to indicate the relative priority of this LLN compared to other PANIDs. Lower values indicate greater willingness to accept new nodes.

ip

protocol-element §2

The proxy priority field (7 bits) indicates the sender's willingness to act as a Join Proxy per RFC 9031. Values range from 0x00 (most willing) to 0x7e (least willing); 0x7f means never consider this node as a viable Join Proxy.

ip

protocol-element §2

The R flag (RA Router flag) indicates whether the sending node will act as a router for host-only SLAAC nodes. When not set, it may indicate the node is under-provisioned or has no slots for additional nodes.

ip

protocol-element §2

The rank priority field (12 bits) is set by the 6LR and indicates willingness to serve as an RPL parent within a particular network ID. Lower values indicate more willingness; typically derived from RPL rank with possible modifications for current load.

ip

registry §5

IANA has assigned value 2 with Subtype ID '6tisch-Join-Info' in the 'IEEE Std 802.15.4 IETF IE Subtype IDs' registry defined by RFC 8137, with reference to RFC 9032.

registry

security-consideration §3

All contents of the IE are transmitted in the clear; the EB is not encrypted. This is a restriction of the 802.15.4 cryptographic architecture, since the TSCH ASN (carried in the EB) is needed to decrypt Layer 2 frames. Pledges cannot authenticate beacons before enrollment and must temporarily trust the contents on faith.

security

security-consideration §3

The EB is authenticated at Layer 2 using 802.15.4 mechanisms with network-wide keying material, but only enrolled nodes possess those keys. Pledges are unable to validate beacons until after enrollment.

security

security-consideration §3

The rank priority and PAN priority fields can be used by an attacker to identify nodes with more traffic or more network resources, making them higher-value targets for attack or disruption.

security

security-consideration §3

The TSCH schedule carried in the EB reveals channels and frequencies in use, enabling an attacker to more efficiently jam communications. Encrypting the schedule would increase jamming energy cost but not prevent it.

security

wire-format §2

The IE subtype structure is a variable-length field starting with a 1-byte subtype ID (value 2), followed by R bit (1), P bit (1), 3 reserved bits, 7-bit proxy priority, 12-bit rank priority, 8-bit PAN priority, optional 64-bit Join Proxy Interface ID (present if P=1), and a variable-length network ID field of up to 16 bytes. The length of the subtype content is calculated from the container per RFC 8137.

ip