One document matched: draft-kivinen-802-15-ie-04.xml
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY rfc2119 PUBLIC ''
'http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml'>
]>
<rfc category='info' ipr='trust200902'
docName='draft-kivinen-802-15-ie-04.txt'>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc toc='yes' ?>
<?rfc symrefs='yes' ?>
<?rfc sortrefs='yes'?>
<?rfc iprnotified='no' ?>
<?rfc compact='yes' ?>
<?rfc strict='yes' ?>
<front>
<title>IEEE 802.15.4 Information Element for IETF</title>
<author initials='T.' surname='Kivinen' fullname='Tero Kivinen'>
<organization>INSIDE Secure</organization>
<address>
<postal>
<street>Eerikinkatu 28</street>
<code>FI-00180</code>
<city>HELSINKI</city>
<country>FI</country>
</postal>
<email>kivinen@iki.fi</email>
</address>
</author>
<author fullname="Pat Kinney" initials="P." surname="Kinney">
<organization>Kinney Consulting LLC</organization>
<address>
<postal>
<street/>
<city/>
<region/>
<code/>
<country/>
</postal>
<email>pat.kinney@kinneyconsultingllc.com</email>
</address>
</author>
<date year='2016' />
<area>Internet</area>
<abstract>
<t>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 IETF, and
describes how the IE is formatted to provide subtypes.</t>
</abstract>
</front>
<middle>
<section title='Introduction'>
<t>IEEE Std. 802.15.4 <xref target="IEEE-802-15-4" /> defines
Information Elements (IEs) that can be used to extend 802.15.4 in
an interoperable manner. There are two different IE types, Header
IE and Payload IE. A Header IE is part of the Medium Access
Control (MAC) header; it is never encrypted, but 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.</t>
<t>IETF protocols will need to insert information in the 802.15.4
frames; the 802.15.4 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) <xref
target='IEEE-802-15-ANA' />. The current 802.15 ANA database can
be found at <xref target='IEEE-802-15-ANA-DB' />.</t>
<t>The 802.15.4 operations manual <xref target='IEEE-802-15-OPS'
/> describes how a standardization 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.</t>
<t>This document provides the information needed for the
request.</t>
</section>
<section anchor="terminology" title="Terminology">
<t>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 <xref
target='RFC2119'/>.</t>
</section>
<section title="Working Groups Benefitting from the IETF 802.15.4 IE" anchor="users">
<t>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 is expected to satisfy that need.</t>
</section>
<section title='IETF IE Subtype Format' anchor='ietf-ie'>
<t>The maximum length of the Payload IE content is 2047 octets,
and 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.</t>
<t>Because the frame contains a list of payload IEs, there is no
need for this document to specify the internal structure inside
the IETF IE. The Payload IE format of IEEE 802.15.4 contains the
Length field. The length of the subtype content can be calculated
from the IEEE 802.15.4 Payload IE Length field of the IETF IE.</t>
<t>The format of the IETF IE is as follows:</t>
<figure anchor="ietf-ie-figure" title="IETF IE Subtype Format" ><artwork><![CDATA[
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 ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork></figure>
<t><list style="symbols">
<t>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.</t>
<t>Subtype content is the actual content of the information
element, and its length can be calculated from the Length field
of the IETF IE. </t>
</list></t>
<t>One IEEE 802.15.4 frame MAY contain multiple IETF IEs with the
same or different subtypes.</t>
</section>
<section title="Request to allocate IETF IE">
<t>The IETF requests that the 802.15 Working Group allocate an ID
for a Payload IE for IETF use. Furthermore the IETF understands
that only one ID will be issued to it.</t>
</section>
<section title='Security Considerations'>
<t>This document creates an IANA registry for IETF IE subtype ID
(see <xref target='iana'/>). The security of the protocols using
the IEs MUST be described in the documents requesting allocations
from this registry.</t>
<t>The IEEE Std 802.15.4-2015 <xref target="IEEE-802-15-4" />
contains methods where 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 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.</t>
</section>
<section title='IANA Considerations' anchor='iana'>
<t>This document creates a new registry for IETF IE subtype IDs
registry:</t>
<figure><artwork><![CDATA[
Value Subtype ID
0 Reserved
1-200 Unassigned
201-255 Experimental Use
]]></artwork></figure>
<t>Any change or addition to this registry requires expert
review.</t>
<t>Note, that there is Vendor specific IEs already defined in the
IEEE 802.15.4 (see <xref target="vendor" />), and because of this,
there is no need to reserve any subtype IDs for the
vendor-specific uses.</t>
</section>
</middle>
<back>
<references title="Normative References">
&rfc2119;
</references>
<references title='Informative References'>
<reference anchor='IEEE-802-15-4'>
<front>
<title>IEEE Standard for Low-Rate Wireless Personal Area
Networks (WPANs)</title>
<author></author>
<date year='2015'/>
</front>
<seriesInfo name="IEEE" value="Standard 802.15.4" />
</reference>
<reference anchor='IEEE-802-15-ANA'
target="http://www.ieee802.org/15/ANA.html">
<front>
<title>IEEE 802.15 Assigned Numbers Authority</title>
<author></author>
<date />
</front>
</reference>
<reference anchor='IEEE-802-15-ANA-DB'
target='https://mentor.ieee.org/802.15/documents?is_dcn=257&is_group=0000'>
<front>
<title>IEEE 802.15 ANA database</title>
<author></author>
<date />
</front>
</reference>
<reference anchor='IEEE-802-15-OPS'
target='https://mentor.ieee.org/802.15/documents?is_dcn=235&is_group=0000'>
<front>
<title>IEEE 802.15 Operations Manual</title>
<author></author>
<date />
</front>
</reference>
</references>
<section title="Vendor Specific IE in IEEE 802.15.4" anchor='vendor'>
<t>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.</t>
</section>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-22 16:56:07 |