IEEE 802.15.4 Information Element for IETF

IEEE Std. 802.15.4 has Information Elements (IE) that can be used to extend 802.15.4 in an interoperable manner. There are two different IE types, Header IE and Payload IE. The Header IEs are part of the Medium Access Control (MAC) header, and are never encrypted, but they may be authenticated. Most of the Header IE processing is done by the MAC, and IETF protocols should not need to extend them. The Payload IEs are part of the MAC payload and they may be encrypted and authenticated. IETF protocols will need to include information in the 802.15.4 frames; the standard 802.15.4 way of doing this is to include one or more payload IEs in the frame that will contain the information. Because of this, the IETF needs to obtain a dedicated Payload IE from the IEEE 802.15 Assigned Numbers Authority (ANA) . The up-to-date 802.15 ANA database can be found at . The 802.15.4 operations manual provides information on how a standardization organization may request an allocation of an IE. To make this request the standardization organization needs to: provide the reason for the request; a description of the protocol format that shows there is sufficient subtype capability; a statement that the external organization understands that only one ID number will be issued. This document provides the information needed for the request.

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in .

There are several IETF working groups such as 6TiSCH, 6lo, CoRE etc, which could benefit from the IETF IE. The 6TiSCH working group has already expressed the need for the IE, and this allocation should provide them a way forward.

The maximum length of the Payload IE content is 2047 octets, and 802.15.4 frame contains a list of payload IEs, i.e. a single frame can have multiple payload IEs, terminated with the payload IE terminator, and may be followed by the payload. Because the frame contains a list of payloads, there is no need to provide internal structure inside the IETF IE. The Payload IE format of the 802.15.4 contains the Length field, so the length of the Sub-Type Content can be calculated from the Length field of the IETF IE. The format of the IETF IE is as follows:

Sub-Type ID is the IANA allocated number specifying the sub-type of the IETF IE. Value 0 is reserved for future extensibility, i.e., in case a longer Sub-Type ID field is needed. Sub-Type Content is the actual content of the information element, and its length can be calculated from the Length field of the IETF IE. One IEEE 802.15.4 frame can contain multiple IETF IEs with the same or different sub types.

IEEE 802.15.4 has already several numbers for different Vendor Specific IE types. There is one for the Vendor Specific Header IE for Header IEs. There is one incorrectly named Vendor Specific Nested IE for Payload IEs, and there is another one with exactly the same name, but under the MLME Nested IE long format. All of the Vendor Specific IEs start with a 3-octet vendor OUI to identify the organization. Because of this, there is no need to reserve the specific Sub-Type IDs for the vendor-specific uses, as those other IE types can be used for that.

IETF would request the 802.15.4 Working Group to allocate a Payload IE for IETF use. Furthermore IETF understands that only one ID will be issued to it.

This document creates an IANA registry for IETF IE Sub-type IDs, and the security of the protocols using the IEs needs to be described in the actual documents allocating values from this registry. The IEEE Std 802.15.4-2015 contains methods where security of the IE can be enforced when a frame is received, but this is only per IE type, thus all IETF IEs will have same security level requirements regardless of the Sub-Type ID used. This can cause issues if different security processing would be needed and any of those IEs would need to be processed in the MAC level. Fortunately, everything IETF does should be in a higher level than the MAC level, thus the higher layer processing for these IEs needs to perform separate security policy checking based on the IETF IE Sub-Type ID in addition to the checks done by the MAC.

This document creates a new registry for IETF IE Sub-type IDs registry:

Changes and additions to this registry is by expert review.