[要約] RFC 8137は、IETFにおけるIEEE 802.15.4情報要素に関する標準化を目的としています。このRFCは、無線センサネットワークにおける情報要素の定義と使用方法を提供しています。

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 Std 802.15.4は、相互運用可能な方法で802.15.4を拡張するために使用できる情報要素(IE)を定義します。 IEEE 802.15 Assigned Numbers Authority(ANA)は、情報要素のレジストリを管理します。このドキュメントでは、ANAがそのレジストリからIETFに番号を割り当てるようにリクエストを作成し、IEがどのようにフォーマットされてサブタイプを提供するかについて説明します。

Status of This Memo

本文書の状態

This document is not an Internet Standards Track specification; it is published for informational purposes.

このドキュメントはInternet Standards Trackの仕様ではありません。情報提供を目的として公開されています。

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(Internet Engineering Task Force)の製品です。これは、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.

Copyright(c)2017 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。

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)の対象であり、この文書の発行日に有効です。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。

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
1. はじめに

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]およびその他のドキュメントで参照されている標準であり、非常に低コストで低電力の通信を可能にします。この規格では、シンプルで効果的なメディアアクセスコントロール(MAC)を使用して、多くの異なる周波数帯域で動作する多数のオプションの物理層(PHY)を定義しています。

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 Std 802.15.4は、相互運用可能な方法で802.15.4を拡張するために使用できる情報要素(IE)を定義します。 IEは、情報をカプセル化するための柔軟で拡張性があり、簡単に実装できる方法を提供します。 IEEE Std 802.15.4-2015 [IEEE802.15.4]のセクション7.4で定義されているIEの一般的な形式は、識別(ID)フィールド、長さフィールド、およびコンテンツフィールドで構成されています。複数のIEを連結できます。また、IEのリストでID値が不明な要素は、長さがわかっているためスキップできます。 IEは、下位互換性のある方法で標準の将来のバージョンに新しい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の2つの異なる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標準では、情報を含むフレームに1つ以上のペイロードIEを含めることで、IEEEを有効にしています。この目的のために、IETFはIEEE 802.15 Assigned Numbers Authority(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)が1つのIEの割り当てを要求する方法が記載されています。この要求を行うために、SDOは(i)要求の理由、(ii)適切なサブタイプ機能を示すプロトコル形式の説明、および(iii)使用のために1つのIE番号のみが割り当てられるという合意を提供する必要があります。 SDOによって。

This document provides the information needed for the request.

このドキュメントは、リクエストに必要な情報を提供します。

2. Terminology
2. 用語

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.

キーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「NOT RECOMMENDED」、「MAY」、「OPTIONALこのドキュメントの「」は、BCP 14 [RFC2119] [RFC8174]で説明されているように解釈されます。

3. Working Groups Benefiting from the IETF 802.15.4 IE
3. IETF 802.15.4 IEを活用するワーキンググループ

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 IEの恩恵を受けることができる6TiSCH、6lo、CoREなどのいくつかのIETFワーキンググループがあります。 6TiSCHワーキンググループは、IEの必要性をすでに表明しています。この割り当ては、そのニーズを満たすことが期待されています。

4. IETF IE Subtype Format
4. IETF 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 Payload IE Lengthフィールドから計算できます。

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                         ~
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        

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 サブタイプIDは、IETF IEのサブタイプを指定するIANA割り当て番号です。値0は将来の拡張性のために予約されています。つまり、より長いサブタイプ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.

1つのIEEE 802.15.4フレームには、同じまたは異なるサブタイプの複数のIETF IEが含まれる場合があります。

5. Request to Allocate an IETF IE
5. IETF IEの割り当て要求

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であることを理解しています。

6. Security Considerations
6. セキュリティに関する考慮事項

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を参照)。 IEを使用するプロトコルのセキュリティは、このレジストリからの割り当てを要求するドキュメントに記述されている必要があります。

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 IEには同じセキュリティレベル要件があります。異なるセキュリティ処理が必要で、これらのIEのいずれかをMACレベルで処理する必要がある場合、これにより問題が発生する可能性があります。すべてのIETFプロトコルはMACレベルよりも高いレベルで動作する必要があるため、これらのIEの上位層処理は、MACによるチェックに加えて、IETF IEサブタイプIDに基づいて個別のセキュリティポリシーチェックを実行する必要があります(SHOULD)。

7. IANA Considerations
7. IANAに関する考慮事項

The "IEEE Std 802.15.4 IETF IE Subtype IDs" registry has been created as follows:

「IEEE Std 802.15.4 IETF IE Subtype IDs」レジストリは次のように作成されました。

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ですでに定義されているベンダー固有のIEがあることに注意してください(付録Aを参照)。このため、ベンダー固有の使用のためにサブタイプIDを予約する必要はありません。

8. References
8. 参考文献
8.1. Normative References
8.1. 引用文献

[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>。

8.2. Informative References
8.2. 参考引用

[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 Standard for Low-Rate Wireless Networks」、IEEE Standard 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 Assigned Numbers Authority」、<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/documents?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/documents?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。、クシャルナガル、N。、ホイ、J。、およびD.キュラー、「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、「RFCでIANAの考慮事項セクションを作成するためのガイドライン」、BCP 26、RFC 5226、DOI 10.17487 / RFC5226、2008年5月、<http://www.rfc-editor.org / info / rfc5226>。

Appendix A. Vendor Specific IE in IEEE 802.15.4
付録A.IEEE 802.15.4のベンダー固有IE

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用のものがあります。ベンダー固有の名前が誤って1つあります

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.

ペイロードIEのネストされたIE、およびまったく同じ名前の別のIEがありますが、MLMEのネストされたIEロングフォーマットの下にあります。ベンダー固有のIEはすべて、組織を識別するために3オクテットのベンダーOUIで始まります。

Authors' Addresses

著者のアドレス

Tero Kivinen INSIDE Secure Lonnrotinkatu 11 Helsinki FI-00120 Finland

Tero Kivinen INSIDE Secure Lonnrotinkatu 11 Helsinki FI-00120フィンランド

   Email: kivinen@iki.fi
        

Pat Kinney Kinney Consulting LLC

パット・キニーキニー・コンサルティングLLC

   Email: pat.kinney@kinneyconsultingllc.com