1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
|
<pre>Internet Engineering Task Force (IETF) T. Kivinen
Request for Comments: 8137 INSIDE Secure
Category: Informational P. Kinney
ISSN: 2070-1721 Kinney Consulting LLC
May 2017
<span class="h1">IEEE 802.15.4 Information Element for the IETF</span>
Abstract
IEEE 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.
Status of This Memo
This document is not an Internet Standards Track specification; it is
published for informational purposes.
This document is a product of the Internet Engineering Task Force
(IETF). It represents the consensus of the IETF community. It has
received public review and has been approved for publication by the
Internet Engineering Steering Group (IESG). Not all documents
approved by the IESG are a candidate for any level of Internet
Standard; see <a href="./rfc7841#section-2">Section 2 of RFC 7841</a>.
Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
<a href="http://www.rfc-editor.org/info/rfc8137">http://www.rfc-editor.org/info/rfc8137</a>.
Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to <a href="https://www.rfc-editor.org/bcp/bcp78">BCP 78</a> and the IETF Trust's Legal
Provisions Relating to IETF Documents
(<a href="http://trustee.ietf.org/license-info">http://trustee.ietf.org/license-info</a>) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
<span class="grey">Kivinen & Kinney Informational [Page 1]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-2" ></span>
<span class="grey"><a href="./rfc8137">RFC 8137</a> IEEE 802.15.4 Information Element for IETF May 2017</span>
Table of Contents
<a href="#section-1">1</a>. Introduction . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-2">2</a>
<a href="#section-2">2</a>. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-3">3</a>
<a href="#section-3">3</a>. Working Groups Benefiting from the IETF 802.15.4 IE . . . . . <a href="#page-3">3</a>
<a href="#section-4">4</a>. IETF IE Subtype Format . . . . . . . . . . . . . . . . . . . <a href="#page-3">3</a>
<a href="#section-5">5</a>. Request to Allocate an IETF IE . . . . . . . . . . . . . . . <a href="#page-4">4</a>
<a href="#section-6">6</a>. Security Considerations . . . . . . . . . . . . . . . . . . . <a href="#page-4">4</a>
<a href="#section-7">7</a>. IANA Considerations . . . . . . . . . . . . . . . . . . . . . <a href="#page-5">5</a>
<a href="#section-8">8</a>. References . . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-6">6</a>
<a href="#section-8.1">8.1</a>. Normative References . . . . . . . . . . . . . . . . . . <a href="#page-6">6</a>
<a href="#section-8.2">8.2</a>. Informative References . . . . . . . . . . . . . . . . . <a href="#page-6">6</a>
<a href="#appendix-A">Appendix A</a>. Vendor Specific IE in IEEE 802.15.4 . . . . . . . . <a href="#page-7">7</a>
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-7">7</a>
<span class="h2"><a class="selflink" id="section-1" href="#section-1">1</a>. Introduction</span>
IEEE Std 802.15.4 [<a href="#ref-IEEE802.15.4">IEEE802.15.4</a>] is a standard, referred to by <a href="./rfc4944">RFC</a>
<a href="./rfc4944">4944</a> [<a href="./rfc4944" title=""Transmission of IPv6 Packets over IEEE 802.15.4 Networks"">RFC4944</a>] and other documents, that enables very low-cost and
low-power communications. The standard defines numerous optional
Physical Layers (PHYs) operating in many different frequency bands
with a simple and effective Medium Access Control (MAC).
IEEE Std 802.15.4 defines Information Elements (IEs) that can be used
to extend 802.15.4 in an interoperable manner. An IE provides a
flexible, extensible, and easily implementable method of
encapsulating information. The general format of an IE as defined in
<a href="#section-7.4">Section 7.4</a> of IEEE Std 802.15.4-2015 [<a href="#ref-IEEE802.15.4">IEEE802.15.4</a>] consists of an
identification (ID) field, a length field, and a content field.
Multiple IEs may be concatenated, and elements with unknown ID values
in a list of IEs can be skipped since their length is known. IEs
provide a flexible container for information that allows the addition
of new IE definitions in future versions of the standard in a
backwards-compatible manner.
There are two different IE types, Header IE and Payload IE. A Header
IE is part of the MAC header; it is never encrypted, but it may be
authenticated. Most of the Header IE processing is done by the MAC,
and IETF protocols should not have any direct effect on that
processing. A Payload IE is part of the MAC payload and may be
encrypted and authenticated.
IETF protocols will need to insert information in the 802.15.4
frames; the 802.15.4 standard enables that by including one or more
payload IEs in the frame that will contain the information. For this
purpose, the IETF requests a dedicated Payload IE from the IEEE
802.15 Assigned Numbers Authority (ANA) [<a href="#ref-IEEE802.15-ANA">IEEE802.15-ANA</a>]. The
current 802.15 ANA database can be found at [<a href="#ref-IEEE802.15-ANA-DB">IEEE802.15-ANA-DB</a>].
<span class="grey">Kivinen & Kinney Informational [Page 2]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-3" ></span>
<span class="grey"><a href="./rfc8137">RFC 8137</a> IEEE 802.15.4 Information Element for IETF May 2017</span>
The 802.15.4 operations manual [<a href="#ref-IEEE802.15-OPS">IEEE802.15-OPS</a>] describes how a
Standards Development Organization (SDO) may request an allocation of
one IE. To make this request the SDO has to provide (i) the reason
for the request, (ii) a description of the protocol format that shows
an appropriate subtype capability, and (iii) an agreement that only
one IE number will be allocated for use by the SDO.
This document provides the information needed for the request.
<span class="h2"><a class="selflink" id="section-2" href="#section-2">2</a>. Terminology</span>
The 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 <a href="https://www.rfc-editor.org/bcp/bcp14">BCP 14</a> [<a href="./rfc2119" title=""Key words for use in RFCs to Indicate Requirement Levels"">RFC2119</a>] [<a href="./rfc8174" title=""Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words"">RFC8174</a>] when, and only when, they
appear in all capitals, as shown here.
<span class="h2"><a class="selflink" id="section-3" href="#section-3">3</a>. Working Groups Benefiting from the IETF 802.15.4 IE</span>
There are several IETF working groups such as 6TiSCH, 6lo, and CoRE
that could benefit from the IETF IE. The 6TiSCH Working Group has
already expressed the need for the IE; this allocation is expected to
satisfy that need.
<span class="h2"><a class="selflink" id="section-4" href="#section-4">4</a>. IETF IE Subtype Format</span>
The maximum length of the Payload IE content is 2047 octets, and the
802.15.4 frame contains a list of payload IEs. A single frame can
have multiple payload IEs, terminated with the payload IE terminator,
which may then be followed by the payload.
Since the 802.15.4 standard defines a list of payload IEs along with
their structures, there is no need for this document to specify the
internal nesting structure of the IETF IE. The Payload IE format of
802.15.4 standard contains the Length field. The length of the
subtype content can be calculated from the 802.15.4 Payload IE Length
field of the IETF IE.
<span class="grey">Kivinen & Kinney Informational [Page 3]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-4" ></span>
<span class="grey"><a href="./rfc8137">RFC 8137</a> IEEE 802.15.4 Information Element for IETF May 2017</span>
The format of the IETF IE is as follows:
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Subtype ID | |
+-+-+-+-+-+-+-+-+ |
~ subtype content ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: IETF IE Subtype Format
o Subtype ID is the IANA-allocated number specifying the subtype of
the IETF IE. Value 0 is reserved for future extensibility, i.e.,
in case a longer subtype ID field is needed.
o Subtype 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 MAY contain multiple IETF IEs with the same
or different subtypes.
<span class="h2"><a class="selflink" id="section-5" href="#section-5">5</a>. Request to Allocate an IETF IE</span>
Per the IETF's request, the IEEE 802.15 Working Group has allocated
an ID (5) for a Payload IE for IETF use. The IETF understands that
this is the only ID it will be issued.
<span class="h2"><a class="selflink" id="section-6" href="#section-6">6</a>. Security Considerations</span>
This document creates an IANA registry for IETF IE subtype IDs (see
<a href="#section-7">Section 7</a>). The security of the protocols using the IEs MUST be
described in the documents requesting allocations from this registry.
The IEEE Std 802.15.4 [<a href="#ref-IEEE802.15.4">IEEE802.15.4</a>] contains methods in which
security of the IE can be enforced when a frame is received, but this
is only per IE type. Therefore, all IETF IEs will have the same
security-level requirements regardless of the subtype 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. Since
all IETF protocols should operate at a higher level than the MAC
level, the higher-layer processing for these IEs SHOULD perform
separate security policy checking based on the IETF IE subtype ID in
addition to the checks done by the MAC.
<span class="grey">Kivinen & Kinney Informational [Page 4]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-5" ></span>
<span class="grey"><a href="./rfc8137">RFC 8137</a> IEEE 802.15.4 Information Element for IETF May 2017</span>
<span class="h2"><a class="selflink" id="section-7" href="#section-7">7</a>. IANA Considerations</span>
The "IEEE Std 802.15.4 IETF IE Subtype IDs" registry has been created
as follows:
Value Subtype ID
0 Reserved
1-200 Unassigned
201-255 Experimental Use
Any change or addition to this registry requires Expert Review
[<a href="./rfc5226" title="">RFC5226</a>].
Note that there are vendor-specific IEs already defined in IEEE
802.15.4 (see <a href="#appendix-A">Appendix A</a>); because of this, there is no need to
reserve any subtype IDs for the vendor-specific uses.
<span class="grey">Kivinen & Kinney Informational [Page 5]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-6" ></span>
<span class="grey"><a href="./rfc8137">RFC 8137</a> IEEE 802.15.4 Information Element for IETF May 2017</span>
<span class="h2"><a class="selflink" id="section-8" href="#section-8">8</a>. References</span>
<span class="h3"><a class="selflink" id="section-8.1" href="#section-8.1">8.1</a>. Normative References</span>
[<a id="ref-RFC2119">RFC2119</a>] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", <a href="https://www.rfc-editor.org/bcp/bcp14">BCP 14</a>, <a href="./rfc2119">RFC 2119</a>,
DOI 10.17487/RFC2119, March 1997,
<<a href="http://www.rfc-editor.org/info/rfc2119">http://www.rfc-editor.org/info/rfc2119</a>>.
[<a id="ref-RFC8174">RFC8174</a>] Leiba, B., "Ambiguity of Uppercase vs Lowercase in <a href="./rfc2119">RFC</a>
<a href="./rfc2119">2119</a> Key Words", <a href="https://www.rfc-editor.org/bcp/bcp14">BCP 14</a>, <a href="./rfc8174">RFC 8174</a>, DOI 10.17487/RFC8174,
May 2017, <<a href="http://www.rfc-editor.org/info/rfc8174">http://www.rfc-editor.org/info/rfc8174</a>>.
<span class="h3"><a class="selflink" id="section-8.2" href="#section-8.2">8.2</a>. Informative References</span>
[<a id="ref-IEEE802.15.4">IEEE802.15.4</a>]
IEEE, "IEEE Standard for Low-Rate Wireless Networks",
IEEE Standard 802.15.4,
<<a href="https://standards.ieee.org/about/get/802/802.15.html">https://standards.ieee.org/about/get/802/802.15.html</a>>.
[<a id="ref-IEEE802.15-ANA">IEEE802.15-ANA</a>]
IEEE 802.15, "IEEE 802.15 Assigned Numbers Authority",
<<a href="http://www.ieee802.org/15/ANA.html">http://www.ieee802.org/15/ANA.html</a>>.
[<a id="ref-IEEE802.15-ANA-DB">IEEE802.15-ANA-DB</a>]
IEEE, "IEEE 802.15 ANA database",
<<a href="https://mentor.ieee.org/802.15/documents?is_dcn=257&is_group=0000">https://mentor.ieee.org/802.15/</a>
<a href="https://mentor.ieee.org/802.15/documents?is_dcn=257&is_group=0000">documents?is_dcn=257&is_group=0000</a>>.
[<a id="ref-IEEE802.15-OPS">IEEE802.15-OPS</a>]
IEEE, "IEEE 802.15 Operations Manual",
<<a href="https://mentor.ieee.org/802.15/documents?is_dcn=235&is_group=0000">https://mentor.ieee.org/802.15/</a>
<a href="https://mentor.ieee.org/802.15/documents?is_dcn=235&is_group=0000">documents?is_dcn=235&is_group=0000</a>>.
[<a id="ref-RFC4944">RFC4944</a>] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler,
"Transmission of IPv6 Packets over IEEE 802.15.4
Networks", <a href="./rfc4944">RFC 4944</a>, DOI 10.17487/RFC4944, September 2007,
<<a href="http://www.rfc-editor.org/info/rfc4944">http://www.rfc-editor.org/info/rfc4944</a>>.
[<a id="ref-RFC5226">RFC5226</a>] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", <a href="https://www.rfc-editor.org/bcp/bcp26">BCP 26</a>, <a href="./rfc5226">RFC 5226</a>,
DOI 10.17487/RFC5226, May 2008,
<<a href="http://www.rfc-editor.org/info/rfc5226">http://www.rfc-editor.org/info/rfc5226</a>>.
<span class="grey">Kivinen & Kinney Informational [Page 6]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-7" ></span>
<span class="grey"><a href="./rfc8137">RFC 8137</a> IEEE 802.15.4 Information Element for IETF May 2017</span>
<span class="h2"><a class="selflink" id="appendix-A" href="#appendix-A">Appendix A</a>. Vendor Specific IE in IEEE 802.15.4</span>
IEEE 802.15.4 already has 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.
Authors' Addresses
Tero Kivinen
INSIDE Secure
Lonnrotinkatu 11
Helsinki FI-00120
Finland
Email: kivinen@iki.fi
Pat Kinney
Kinney Consulting LLC
Email: pat.kinney@kinneyconsultingllc.com
Kivinen & Kinney Informational [Page 7]
</pre>
|
