doc: Add RFC documents

1 files changed, 395 insertions, 0 deletions

diff --git a/doc/rfc/rfc8137.txt b/doc/rfc/rfc8137.txt
new file mode 100644
index 0000000..056e3e2
--- /dev/null
+++ b/doc/rfc/rfc8137.txt
@@ -0,0 +1,395 @@
+
+
+
+
+
+
+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]
+