GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:rfc8137

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

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 Section 2 of RFC 7841.
 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.

Copyright Notice

 Copyright (c) 2017 IETF Trust and the persons identified as the
 document authors.  All rights reserved.
 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.

Kivinen & Kinney Informational [Page 1] RFC 8137 IEEE 802.15.4 Information Element for IETF May 2017

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

 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 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.
 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) [IEEE802.15-ANA].  The
 current 802.15 ANA database can be found at [IEEE802.15-ANA-DB].

Kivinen & Kinney Informational [Page 2] RFC 8137 IEEE 802.15.4 Information Element for IETF May 2017

 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.
 This document provides the information needed for the request.

2. Terminology

  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.

3. Working Groups Benefiting from the 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.

4. IETF IE Subtype Format

 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.

Kivinen & Kinney Informational [Page 3] RFC 8137 IEEE 802.15.4 Information Element for IETF May 2017

 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.

5. Request to Allocate an 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.

6. Security Considerations

 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.
 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.

Kivinen & Kinney Informational [Page 4] RFC 8137 IEEE 802.15.4 Information Element for IETF May 2017

7. IANA Considerations

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

Kivinen & Kinney Informational [Page 5] RFC 8137 IEEE 802.15.4 Information Element for IETF May 2017

8. References

8.1. Normative References

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

8.2. Informative References

 [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-DB]
            IEEE, "IEEE 802.15 ANA database",
            <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>.
 [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>.
 [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>.

Kivinen & Kinney Informational [Page 6] RFC 8137 IEEE 802.15.4 Information Element for IETF May 2017

Appendix A. Vendor Specific IE in IEEE 802.15.4

 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]

/data/webs/external/dokuwiki/data/pages/rfc/rfc8137.txt · Last modified: 2017/05/27 04:37 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki