6lo S. Chakrabarti Internet-Draft Updates: 4944, 6282 (if approved) G. Montenegro Intended status: Standards Track Microsoft Expires: June 11, 2017 R. Droms J. Woodyatt Google December 8, 2016 6lowpan ESC Dispatch Code Points and Guidelines draft-ietf-6lo-dispatch-iana-registry-07 Abstract RFC4944 defines the ESC dispatch type to allow for additional dispatch octets in the 6lowpan header. The value of the ESC dispatch type was updated by RFC6282, however, its usage was not defined either in RFC6282 or in RFC4944. This document updates RFC4944 and RFC6282 by defining the ESC extension octet code points including registration of entries for known use cases at the time of writing of this document. Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on June 11, 2017. Copyright Notice Copyright (c) 2016 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 Chakrabarti, et al. Expires June 11, 2017 [Page 1] Internet-Draft IANA-6lo-dispatch December 2016 (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. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Usage of ESC dispatch octets . . . . . . . . . . . . . . . . . 3 3.1. Interaction with other RFC4944 implementations . . . . . . 4 3.2. ESC Extension Octets Typical Sequence . . . . . . . . . . . 5 3.3. ITU-T G.9903 ESC type usage . . . . . . . . . . . . . . . 6 3.4. NALP and ESC dispatch types . . . . . . . . . . . . . . . . 6 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 7 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 7.1. Normative References . . . . . . . . . . . . . . . . . . . 8 7.2. Informative References . . . . . . . . . . . . . . . . . . 8 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8 Chakrabarti, et al. Expires June 11, 2017 [Page 2] Internet-Draft IANA-6lo-dispatch December 2016 1. Introduction [RFC4944] section 5.1 defines the dispatch header and types. The ESC type is defined for using additional dispatch octets in the 6lowpan header. RFC 6282 modifies the value of the ESC dispatch type and that value is recorded in IANA registry [6LOWPAN-IANA]. However, the octets and usage following the ESC dispatch type are not defined in either [RFC4944] and [RFC6282]. In recent years with 6lowpan deployments, implementations and standards organizations have started using the ESC extension octets. This highlights the need for an updated IANA registration policy. The following sections record the ITU-T specification for ESC dispatch octet code points as an existing known usage and propose the definition of ESC extension octets for future applications. The document also requests IANA actions for the first extension octet following the ESC dispatch type. 2. Terminology 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 [RFC2119]. 3. Usage of ESC dispatch octets RFC 4944 [RFC4944] first introduces this "ESC" dispatch header type for extension of dispatch octets. RFC 6282 [RFC6282] subsequently modified its value to [01 000000]. This document specifies that the first octet following the ESC dispatch type be used for extension type (extended dispatch values). Subsequent octets are left unstructured for the specific use of the extension type: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ESC | ESC EXT Type | Extended Dispatch Payload +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 1: Frame Format with ESC dispatch type ESC: The left-most octet is the ESC dispatch type containing Chakrabarti, et al. Expires June 11, 2017 [Page 3] Internet-Draft IANA-6lo-dispatch December 2016 '01000000' ESC Extension Type (EET): It is the first octet following the ESC dispatch type. Extension type defines the payload for the additional dispatch octets. The values are from 0 to 255. Values 0 and 255 are reserved for future use. The remaining values from 1 to 254 are assigned by IANA. The EET values are similar to dispatch values in the 6lowpan header except they are preceded by the ESC dispatch type. Thus, ESC extension types and dispatch values are using orthogonal code spaces. Though not desirable, multiple ESC dispatch types MAY appear in a 6lowpan header. Section 3.1 describes how to handle an unknown ESC dispatch type. Extended Dispatch Payload (EDP): This part of the frame format must be defined by the corresponding extension type. A specification is required to define each usage of extension type and its corresponding Extension Payload. For the sake of interoperability, specifications of extension octets MUST NOT redefine the existing ESC Extension Type codes. Section 5.1 in RFC4944 indicates that the Extension Type field may contain additional dispatch values larger than 63, as corrected by [4944-ERRATA]. For the sake of interoperability, the new dispatch type (EET) MUST NOT modify the behavior of existing dispatch types [RFC4944]. 3.1. Interaction with other RFC4944 implementations It is expected that existing implementations of RFC4944 are not capable of processing ESC extension data octets as defined in this document. However, implementers have to assume that existing implementation that attempt to process an EET unknown to them will simply drop the packet or ignore the ESC dispatch octets. If an implementation following this document, during processing of the received packet reaches an ESC dispatch type for which it does not understand the extension octets (EET), it MUST drop that packet. However, it is important to clarify that a router node SHOULD forward a 6lowpan packet with the EET octets as long as it does not attempt to process any unknown ESC extension octets. Multiple ESC extension octets may appear in a packet. The ESC dispatch types can appear as the first, last or middle dispatch octets. However, a packet will get dropped by any node that does not understand the EET at the beginning of the packet. Placing an EET toward the front of the packet has a greater probability of causing the packet to be dropped than placing the same EET later in the packet. Placement of an EET later in the packet increases the chance Chakrabarti, et al. Expires June 11, 2017 [Page 4] Internet-Draft IANA-6lo-dispatch December 2016 that a legacy device will recognize and successfully process some dispatch type [RFC4944] before the EET. In this case, the legacy device will ignore the EET instead of dropping the entire packet. 3.2. ESC Extension Octets Typical Sequence ESC Extension octets sequence and order with respect to 6LoWPAN Mesh header and LoWPAN_IPHC header are described below. When LOWPAN_IPHC dispatch type is present, ESC dispatch types MUST appear before the LOWPAN_IPHC dispatch type in order to maintain backward compatibility with RFC6282 section 3.2. The following diagrams provide examples of ESC extension octet usages: A LoWPAN encapsulated IPv6 Header compressed packet: +-------+------+--------+--------+-----------------+--------+ | ESC | EET | EDP |Dispatch| LOWPAN_IPHC hdr | Payld | +-------+------+--------+--------+-----------------+--------+ A LoWPAN_IPHC Header, Mesh header and an ESC extension octet: +-----+-----+-----+----+------+-------+---------------+------+ |M typ| Mhdr| ESC | EET|EDP |Disptch|LOWPAN_IPHC hdr| Payld| +-----+-----+-----+----+------+-------+---------------+------+ A Mesh header with ESC dispatch types +-------+-------+-----+-----+-------+ | M Typ | M Hdr | ESC | EET |EDP | +-------+-------+-----+-----+-------+ With Fragment header +-------+-------+--------+------+-----+-----+-------+ | M Typ | M Hdr | F Typ | F hdr|ESC | EET | EDP | +-------+-------+--------+------+-----+-----+-------+ ESC dispatch type as a LowPAN encapsulation +--------+--------+--------+ | ESC | EET | EDP | +--------+--------+--------+ Figure 2: A 6lowpan packet with ESC dispatch types Chakrabarti, et al. Expires June 11, 2017 [Page 5] Internet-Draft IANA-6lo-dispatch December 2016 3.3. ITU-T G.9903 ESC type usage The ESC dispatch type is used in [G3-PLC] to provide native mesh routing and bootstrapping functionalities. The ITU-T recommendation [G3-PLC] section 9.4.2.3 defines commands which are formatted like ESC Extension type fields. The command ID values are 0x01 to 0x1F. The frame format is defined as follows: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0 1| ESC | Command ID | Command Payload +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 3: G.9903 Frame Format with ESC dispatch type 3.4. NALP and ESC dispatch types According to RFC4944 [RFC4944] section 5.1, NALP dispatch octets are reserved for use as a kind of escape code for identification of non- 6lowpan payloads. Since ESC dispatch types are part of 6lowpan dispatch types (extended), they are orthogonal to NALP octets. This document clarifies that NALP dispatch codes only provide an escape method for non-6LoWPAN payloads when they appear as the initial octet of a LoWPAN encapsulation, and that the potential meaning of their appearance in any other location is reserved for future use. 4. IANA Considerations This document requests IANA to register the 'ESC Extension Type' values per the policy 'Specification Required' [RFC5226], following the same policy as in the IANA Considerations section of [RFC4944]. For each Extension Type (except the Reserved values) the specification MUST define corresponding Extended Dispatch Payload frame octets for the receiver implementation to read the ESC dispatch types in an interoperable fashion. [RFC5226] section 4.1 also indicates that "Specification Required" calls for a Designated Expert review of the public specification requesting registration of the ESC Extension Type values. The allocation of code points should follow the guidelines on "Usage Chakrabarti, et al. Expires June 11, 2017 [Page 6] Internet-Draft IANA-6lo-dispatch December 2016 of ESC dispatch octets" and the typical example sections. ESC Extension type code points MUST be used in conjunction with 6lo protocols following [RFC4944] or its derivatives. The requesting document MUST specify how the ESC dispatch octets will be used along with 6LOWPAN headers in their use cases. The initial values for the 'ESC Extension Type' fields are: +-------+---------------------------------+---------------+ | Value | Description | Reference | +-------+---------------------------------+---------------+ | 0 | Reserved for future use | This document | | | | | | 1-31 | Used by ITU-T G.9903 and G.9905 | ITU-T G.9903 &| | | Command IDs | ITU-T G.9905 | | | | | | 32-254| Unassigned | This document | | |(Reserved for future IANA | | | | Assignment-- Spec Required) | | | | | | | 255 | Reserved for future use | This document | +-------+---------------------------------+---------------+ Figure 4: Initial Values for IANA Registry 5. Security Considerations There are no additional security threats due to the assignments of ESC dispatch type usage described in this document. Furthermore, this document forbids defining any extended dispatch values or extension types that modify the behavior of existing Dispatch types. 6. Acknowledgements The authors would like to thank the members of the 6lo WG for their comments. Many thanks to Carsten Bormann, Ralph Droms, Thierry Lys, Cedric Lavenu, Pascal Thubert for discussions regarding the bits allocation issues, which led to this document. Jonathan Hui and Robert Cragie provided extensive reviews and guidance for interoperability. The authors acknowledge the comments from the following people that helped shape this document: Paul Duffy, Don Sturek, Michael Richardson, Xavier Vilajosana, Scott Mansfield, Dale Worley and Russ Housley. Thanks to Brian Haberman, our document shepherd, for guidance in the IANA Considerations section. Chakrabarti, et al. Expires June 11, 2017 [Page 7] Internet-Draft IANA-6lo-dispatch December 2016 This document was produced using the xml2rfc tool. 7. References 7.1. Normative References [4944-ERRATA] "https://www.rfc-editor.org/errata_search.php?rfc=4944". [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/ RFC2119, March 1997, . [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, . [RFC6282] Hui, J., Ed. and P. Thubert, "Compression Format for IPv6 Datagrams over IEEE 802.15.4-Based Networks", RFC 6282, DOI 10.17487/RFC6282, September 2011, . 7.2. Informative References [6LOWPAN-IANA] "https://www.iana.org/assignments/_6lowpan-parameters/ _6lowpan-parameters.xhtml". [6loCHART] "https://datatracker.ietf.org/wg/6lo/charter". [G3-PLC] "http://www.itu.int/rec/T-REC-G.9903-201402-I". [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, . Chakrabarti, et al. Expires June 11, 2017 [Page 8] Internet-Draft IANA-6lo-dispatch December 2016 Authors' Addresses Samita Chakrabarti San Jose, CA USA Email: samitac.ietf@gmail.com Gabriel Montenegro Microsoft USA Email: gabriel.montenegro@microsoft.com Ralph Droms USA Email: rdroms.ietf@gmail.com James Woodyatt Google Mountain View, CA USA Email: jhw@google.com Chakrabarti, et al. Expires June 11, 2017 [Page 9]