6lo S. Chakrabarti Internet-Draft Ericsson Updates: 4944, 6282 (if approved) G. Montenegro Intended status: Standards Track Microsoft Expires: August 28, 2016 R. Droms Cisco J. Woodyatt Nest February 25, 2016 IANA Registry for 6lowpan ESC Dispatch Code points draft-ietf-6lo-dispatch-iana-registry-01 Abstract RFC4944 defines ESC dispatch type for additional dispatch bytes in the 6lowpan header. The value of ESC byte has been updated by RFC6282. However, the usage of ESC extension byte has not been defined in RFC6282 and RFC4944. The purpose of this document is to define the ESC extension byte code points and to request corresponding IANA actions. 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 August 28, 2016. 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 (http://trustee.ietf.org/license-info) in effect on the date of Chakrabarti, et al. Expires August 28, 2016 [Page 1] Internet-Draft IANA-6lo-dispatch February 2016 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 bytes . . . . . . . . . . . . . . . . . . 3 3.1. Interaction with other RFC4944 implementations . . . . . . 4 3.2. ESC Extension Bytes Typical Sequence . . . . . . . . . . . 5 3.3. Example: ITU-T G.9903 ESC type usage . . . . . . . . . . . 5 3.4. NALP and ESC bytes . . . . . . . . . . . . . . . . . . . . 6 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 6 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 7.1. Normative References . . . . . . . . . . . . . . . . . . . 7 7.2. Informative References . . . . . . . . . . . . . . . . . . 7 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8 Chakrabarti, et al. Expires August 28, 2016 [Page 2] Internet-Draft IANA-6lo-dispatch February 2016 1. Introduction [RFC4944] section 5.1 defines the dispatch header and types. The ESC type is defined for using additional dispatch bytes in the 6lowpan header. RFC 6282 modifies the value of the ESC dispatch type and it is recorded in IANA registry [6LOWPAN-IANA]. However, the bytes and usage following the ESC byte are not defined in either [RFC4944] and [RFC6282]. However, in recent years with 6lowpan deployments, the implementations and Standards organizations have started using the ESC extension bytes and a co-ordination between the respective organizations and IETF/IANA are needed. The following sections record the ITU-T specification for ESC dispatch byte code points as an existing known usage and propose the definition of ESC extension bytes for future applications. The document also requests IANA actions for the first extension byte following the ESC byte. 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 bytes RFC 4944 [RFC4944] first introduces this "ESC" dispatch header type for extension of dispatch bytes. RFC 6282 [RFC6282] subsequently modified its value to [01 000000]. This document specifies that the first octet following the ESC byte 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0 1| ESC | ESC EXT Type | Extended Dispatch Payload +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 1: Frame Format with ESC Byte ESC: The left-most byte is the ESC dispatch type containing '0100000' Chakrabarti, et al. Expires August 28, 2016 [Page 3] Internet-Draft IANA-6lo-dispatch February 2016 ESC Extension Type (EET): It is the first byte following the ESC byte. Extension type defines the payload for the additional dispatch bytes. The values are from 0 to 255. Value 0 and 255 are reserved for future use. These values are assigned by IANA. The EET values are similar to dispatch values in the 6lowpan header except they are preceeded by the ESC byte. Thus, ESC extension types and dispatch values are using orthogonal code spaces. Though not desirable, multiple ESC bytes MAY appear in a 6lowpan header. For example, it is possible to form [Mesh-hdr][6lowpan- IPHC][Payload][ESC][EET][Payload][ESC][EET][Payload] as long as it follows the same semantics defined in this document and does not induce fragmentation. Section 3.1 describes how to handle unknown ESC dispatch type. Extended Dispatch Payload(EDP): This part of 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 bytes 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 RFC4944 existing implementations are not capable of processing ESC extension data bytes as defined in this document. However, implementors 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 bytes. If an implementation following this document, during processing of the received packet reaches the ESC byte for which it does not understand the extension bytes (EET), it MUST drop that packet. However, it is important to clarify that a router node SHOULD forward a 6lowpan packet with the EET bytes as long as it does not attempt to process any unknown ESC extension bytes. Sequence Of dispatch bytes and ESC bytes: Multiple ESC extension bytes may appear in a packet. The ESC bytes can appear as the first, last or middle dispatch bytes. However, a packet will get dropped by any node that does not understand the EET at the beginning of the packet. The closer to the end of the packet are the EET's, the higher chance there is that a legacy node will recognize and Chakrabarti, et al. Expires August 28, 2016 [Page 4] Internet-Draft IANA-6lo-dispatch February 2016 successfully process some dispatch type [RFC4944] before the EET and then ignore the EET instead of dropping the entire packet. 3.2. ESC Extension Bytes Typical Sequence The following diagram provides an example when ESC extension bytes might be used: A LoWPAN encapsulated HC1 compressed packet: +----------+-----------------+---------+-----+-----+--------+ | Dispatch | LOWPAN_IPHC hdr | Payld |ESC | EET |EPayld | +----------------------------+---------+-----+-----+--------+ A LoWPAN_IPHC Header, Mesh header and an ESC extenstion byte: +-------+-------+--------+--------+-------+-----+-----+-------+ | M Typ | M Hdr | LOWPAN_IPHC Hdr | Payld |ESC | EET | EPayld| +-------+-------+--------+--------+-------+-----+-----+-------+ Figure 2: A 6lowpan packet with ESC Bytes 3.3. Example: ITU-T G.9903 ESC type usage [G3-PLC] provides native mesh-under functionalities. The ESC dispatch type is used with the command frames specified in figure 9-12 and Table 9-35 in [G3-PLC] . 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 Byte Chakrabarti, et al. Expires August 28, 2016 [Page 5] Internet-Draft IANA-6lo-dispatch February 2016 3.4. NALP and ESC bytes According to RFC4944 [RFC4944] section 5.1, NALP dispatch bytes are used for non-6lowpan packets. Since ESC bytes are part of 6lowpan dispatch types (extended), they are orthogonal to NALP bytes. 4. IANA Considerations This document requests IANA to register the 'ESC Extension Type' values as per the policy 'Specification Required'[RFC5226] as specified in this document which follows the same policy as in the IANA section of [RFC4944]. For each Extension Type (except the Reserved values) the specification MUST define corresponding Extended Dispatch Payload frame bytes for the receiver implementation to read the ESC bytes with interoperability. 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 is no additional security threats due to the assignments of ESC byte usage described in this document. However, this document forbids defining any extended dispatch values or extension types that modifies the behavior of existing Dispatch types. Chakrabarti, et al. Expires August 28, 2016 [Page 6] Internet-Draft IANA-6lo-dispatch February 2016 6. Acknowledgements The authors would like to thank the members of the 6lo WG members for the comments in the mailing list. Many thanks to Carsten Bormann, Ralph Droms, Thierry Lys, Cedric Lavenu, Pascal Thubert for their discussions regarding resolving the bits allocation issues which led to this document. Jonathan Hui and Robert Cregie provided extensive reviews and guidance for interoperability. The authors acknowledges the comments from the following people for shaping this document: Paul Duffy, Don Sturek, Michael Richardson, Xavier Vilajosana and Scott Mansfield. 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". [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 August 28, 2016 [Page 7] Internet-Draft IANA-6lo-dispatch February 2016 Authors' Addresses Samita Chakrabarti Ericsson 300 Holger Way San Jose, CA US Phone: +1 408 750 5843 Email: samita.chakrabarti@ericsson.com Gabriel Montenegro Microsoft Seattle US Email: gabriel.montenegro@microsoft.com Ralph Droms Cisco USA Email: rdroms@cisco.com James Woodyatt Nest Mountain View, CA USA Email: jhw@netstlabs.com Chakrabarti, et al. Expires August 28, 2016 [Page 8]