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
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
IEEE 802.15.4 Information Element for the IETF
IETF的IEEE 802.15.4信息元素
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.
IEEE标准802.15.4定义了可用于以互操作方式扩展802.15.4的信息元素。IEEE 802.15分配号码管理局（ANA）管理信息元素的注册表。本文件规定了ANA从该注册表中为IETF分配一个号码的请求，并描述了IE如何格式化以提供子类型。
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 Section 2 of RFC 7841.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。并非IESG批准的所有文件都适用于任何级别的互联网标准；见RFC 7841第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc8137.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc8137.
Copyright Notice
版权公告
Copyright (c) 2017 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2017 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) 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.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Working Groups Benefiting from the IETF 802.15.4 IE . . . . . 3
4. IETF IE Subtype Format . . . . . . . . . . . . . . . . . . . 3
5. Request to Allocate an IETF IE . . . . . . . . . . . . . . . 4
6. Security Considerations . . . . . . . . . . . . . . . . . . . 4
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 6
8.1. Normative References . . . . . . . . . . . . . . . . . . 6
8.2. Informative References . . . . . . . . . . . . . . . . . 6
Appendix A. Vendor Specific IE in IEEE 802.15.4 . . . . . . . . 7
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Working Groups Benefiting from the IETF 802.15.4 IE . . . . . 3
4. IETF IE Subtype Format . . . . . . . . . . . . . . . . . . . 3
5. Request to Allocate an IETF IE . . . . . . . . . . . . . . . 4
6. Security Considerations . . . . . . . . . . . . . . . . . . . 4
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 6
8.1. Normative References . . . . . . . . . . . . . . . . . . 6
8.2. Informative References . . . . . . . . . . . . . . . . . 6
Appendix A. Vendor Specific IE in IEEE 802.15.4 . . . . . . . . 7
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7
IEEE Std 802.15.4 [IEEE802.15.4] is a standard, referred to by RFC 4944 [RFC4944] 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[IEEE802.15.4]是RFC 4944[RFC4944]和其他文件提及的一种标准，它支持非常低成本和低功耗的通信。该标准定义了许多可选的物理层（PHY），这些物理层通过简单有效的介质访问控制（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 Section 7.4 of IEEE Std 802.15.4-2015 [IEEE802.15.4] 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.
IEEE标准802.15.4定义了可用于以互操作方式扩展802.15.4的信息元素。IE提供了一种灵活、可扩展且易于实现的信息封装方法。IEEE标准802.15.4-2015[IEEE802.15.4]第7.4节中定义的IE的通用格式由标识（ID）字段、长度字段和内容字段组成。可以连接多个IE，并且可以跳过IE列表中ID值未知的元素，因为它们的长度是已知的。IEs提供了一个灵活的信息容器，允许以向后兼容的方式在标准的未来版本中添加新的IE定义。
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.
有两种不同的IE类型，报头IE和有效负载IE。报头IE是MAC报头的一部分；它从不加密，但可能经过身份验证。大多数报头IE处理由MAC完成，IETF协议不应对该处理产生任何直接影响。有效载荷IE是MAC有效载荷的一部分，并且可以被加密和认证。
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) [IEEE802.15-ANA]. The current 802.15 ANA database can be found at [IEEE802.15-ANA-DB].
IETF协议需要在802.15.4帧中插入信息；802.15.4标准通过在包含信息的帧中包含一个或多个有效负载IEs来实现这一点。为此，IETF向IEEE 802.15分配号码管理局（ANA）[IEEE802.15-ANA]请求专用有效负载IE。当前的802.15 ANA数据库可在[IEEE802.15-ANA-DB]上找到。
The 802.15.4 operations manual [IEEE802.15-OPS] 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.
802.15.4操作手册[IEEE802.15-OPS]描述了标准开发组织（SDO）如何请求分配一个IE。为了提出此请求，SDO必须提供（i）请求的原因，（ii）显示适当子类型能力的协议格式说明，以及（iii）仅分配一个IE号供SDO使用的协议。
This document provides the information needed for the request.
本文档提供了请求所需的信息。
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 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“建议”、“不建议”、“可”和“可选”在所有大写字母出现时（如图所示）应按照BCP 14[RFC2119][RFC8174]所述进行解释。
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.
有几个IETF工作组，如6TiSCH、6lo和CoRE，可以从IETF IE中受益。6TiSCH工作组已经表示需要IE；预计这一分配将满足这一需要。
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.
有效负载IE内容的最大长度为2047个八位字节，802.15.4帧包含有效负载IE列表。一个帧可以有多个有效载荷IE，以有效载荷IE终止符终止，随后可能是有效载荷。
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.
由于802.15.4标准定义了有效载荷IE及其结构的列表，因此本文档无需指定IETF IE的内部嵌套结构。802.15.4标准的有效载荷IE格式包含长度字段。子类型内容的长度可根据IETF IE的802.15.4有效负载IE长度字段计算。
The format of the IETF IE is as follows:
IETF IE的格式如下：
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 ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
图1:IETF IE子类型格式
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 ID是指定IETF IE子类型的IANA分配号。值0保留用于将来的扩展性，即，如果需要更长的Subtype ID字段。
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.
o 子类型内容是信息元素的实际内容，其长度可从IETF IE的长度字段计算。
One IEEE 802.15.4 frame MAY contain multiple IETF IEs with the same or different subtypes.
一个IEEE 802.15.4帧可能包含具有相同或不同子类型的多个IETF IEs。
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.
根据IETF的请求，IEEE 802.15工作组为IETF使用的有效载荷IE分配了一个ID（5）。IETF知道这是它将发布的唯一ID。
This document creates an IANA registry for IETF IE subtype IDs (see Section 7). The security of the protocols using the IEs MUST be described in the documents requesting allocations from this registry.
本文档为IETF IE子类型ID创建IANA注册表（见第7节）。使用IEs的协议的安全性必须在从该注册表请求分配的文档中描述。
The IEEE Std 802.15.4 [IEEE802.15.4] 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.
IEEE Std 802.15.4[IEEE802.15.4]包含在接收到帧时可以强制执行IE安全性的方法，但这仅限于每种IE类型。因此，无论使用何种子类型ID，所有IETF IEs都将具有相同的安全级别要求。如果需要不同的安全处理，并且这些IE中的任何一个都需要在MAC级别处理，则这可能会导致问题。由于所有IETF协议应在高于MAC级别的级别上运行，因此这些IEs的高层处理应根据IETF IE子类型ID以及MAC所做的检查执行单独的安全策略检查。
The "IEEE Std 802.15.4 IETF IE Subtype IDs" registry has been created as follows:
“IEEE Std 802.15.4 IETF IE子类型ID”注册表创建如下：
Value Subtype ID 0 Reserved 1-200 Unassigned 201-255 Experimental Use
值子类型ID 0保留1-200未分配201-255实验使用
Any change or addition to this registry requires Expert Review [RFC5226].
对本登记册的任何更改或添加都需要专家审查[RFC5226]。
Note that there are vendor-specific IEs already defined in IEEE 802.15.4 (see Appendix A); because of this, there is no need to reserve any subtype IDs for the vendor-specific uses.
请注意，IEEE 802.15.4中已经定义了特定于供应商的IEs（见附录A）；因此，不需要为特定于供应商的用途保留任何子类型ID。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，DOI 10.17487/RFC2119，1997年3月<http://www.rfc-editor.org/info/rfc2119>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <http://www.rfc-editor.org/info/rfc8174>.
[RFC8174]Leiba，B.，“RFC 2119关键词中大写与小写的歧义”，BCP 14，RFC 8174，DOI 10.17487/RFC8174，2017年5月<http://www.rfc-editor.org/info/rfc8174>.
[IEEE802.15.4] IEEE, "IEEE Standard for Low-Rate Wireless Networks", IEEE Standard 802.15.4, <https://standards.ieee.org/about/get/802/802.15.html>.
[IEEE802.15.4]IEEE，“低速无线网络的IEEE标准”，IEEE标准802.15.4<https://standards.ieee.org/about/get/802/802.15.html>.
[IEEE802.15-ANA] IEEE 802.15, "IEEE 802.15 Assigned Numbers Authority", <http://www.ieee802.org/15/ANA.html>.
[IEEE802.15-ANA]IEEE 802.15，“IEEE 802.15分配号码管理局”<http://www.ieee802.org/15/ANA.html>.
[IEEE802.15-ANA-DB] IEEE, "IEEE 802.15 ANA database", <https://mentor.ieee.org/802.15/ documents?is_dcn=257&is_group=0000>.
[IEEE802.15-ANA-DB]IEEE，“IEEE 802.15 ANA数据库”<https://mentor.ieee.org/802.15/ 文档？is_dcn=257&is_group=0000>。
[IEEE802.15-OPS] IEEE, "IEEE 802.15 Operations Manual", <https://mentor.ieee.org/802.15/ documents?is_dcn=235&is_group=0000>.
[IEEE802.15-OPS]IEEE，“IEEE 802.15操作手册”<https://mentor.ieee.org/802.15/ 文档？is_dcn=235&is_group=0000>。
[RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler, "Transmission of IPv6 Packets over IEEE 802.15.4 Networks", RFC 4944, DOI 10.17487/RFC4944, September 2007, <http://www.rfc-editor.org/info/rfc4944>.
[RFC4944]黑山，G.，Kushalnagar，N.，Hui，J.，和D.Culler，“通过IEEE 802.15.4网络传输IPv6数据包”，RFC 4944，DOI 10.17487/RFC4944，2007年9月<http://www.rfc-editor.org/info/rfc4944>.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, DOI 10.17487/RFC5226, May 2008, <http://www.rfc-editor.org/info/rfc5226>.
[RFC5226]Narten，T.和H.Alvestrand，“在RFCs中编写IANA注意事项部分的指南”，BCP 26，RFC 5226，DOI 10.17487/RFC5226，2008年5月<http://www.rfc-editor.org/info/rfc5226>.
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
IEEE 802.15.4已经为不同的特定于供应商的IE类型提供了多个编号。有一个用于特定于供应商的标题IE用于标题IE。有一个供应商特定的名称不正确
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.
用于有效负载IEs的嵌套IE，还有一个具有完全相同的名称，但在MLME嵌套IE长格式下。所有特定于供应商的IE都以3个八位字节的供应商OUI开始，以识别组织。
Authors' Addresses
作者地址
Tero Kivinen INSIDE Secure Lonnrotinkatu 11 Helsinki FI-00120 Finland
Tero Kivinen内部安全Lonnrotinkatu 11赫尔辛基FI-00120芬兰
Email: kivinen@iki.fi
Email: kivinen@iki.fi
Pat Kinney Kinney Consulting LLC
帕特金尼咨询有限责任公司
Email: pat.kinney@kinneyconsultingllc.com
Email: pat.kinney@kinneyconsultingllc.com