    Internet Engineering Task Force (IETF)                    S. Chakrabarti
    Request for Comments: 8066
    Updates: 4944, 6282                                        G. Montenegro
    Category: Standards Track                                      Microsoft
    ISSN: 2070-1721                                                 R. Droms

                                                                 J. Woodyatt
                                                                      Google
                                                               February 2017

          IPv6 over Low-Power Wireless Personal Area Network (6LoWPAN)
                    ESC Dispatch Code Points and Guidelines

    Abstract

       RFC 4944 defines the ESC dispatch type to allow additional dispatch
       octets in the 6LoWPAN header.  The value of the ESC dispatch type was
       updated by RFC 6282; however, its usage was not defined in either RFC
       6282 or RFC 4944.  This document updates RFC 4944 and RFC 6282 by
       defining the ESC extension octet code points and listing registration
       entries for known use cases at the time of writing of this document.

    Status of This Memo

       This is an Internet Standards Track document.

       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).  Further information on
       Internet Standards is available in 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/rfc8066.

    Chakrabarti, et al.          Standards Track                    [Page 1]

    RFC 8066            6LoWPAN ESC Dispatch Code Points       February 2017

    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.

    Table of Contents

       1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
       2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   3
       3.  Usage of ESC Dispatch Octets  . . . . . . . . . . . . . . . .   3
         3.1.  Interaction with Other RFC 4944 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.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   7
         6.1.  Normative References  . . . . . . . . . . . . . . . . . .   7
         6.2.  Informative References  . . . . . . . . . . . . . . . . .   8
       Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . .   8
       Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   9

    Chakrabarti, et al.          Standards Track                    [Page 2]

    RFC 8066            6LoWPAN ESC Dispatch Code Points       February 2017

    1.  Introduction

       Section 5.1 of [RFC4944] defines the dispatch header and types.  The
       ESC type is defined to use 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 [IANA-6LoWPAN].  However, the
       octets and usage following the ESC dispatch type are not defined in
       either [RFC4944] or [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.

       This document defines the new "ESC Extension Types" registry and the
       ESC extension octets for future applications.  In addition, this
       document records the ITU-T specification for ESC dispatch octet code
       points as an existing known usage.

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

    Chakrabarti, et al.          Standards Track                    [Page 3]

    RFC 8066            6LoWPAN ESC Dispatch Code Points       February 2017

       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 the usage of each 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 of RFC 4944 indicates that the Extension Type field may
       contain additional dispatch values larger than 63, as corrected by
       [Err4359].  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 RFC 4944 Implementations

       It is expected that existing implementations of RFC 4944 are not
       capable of processing ESC extension data octets as defined in this
       document.  However, implementers have to assume that an existing
       implementation that attempts to process an EET that is 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 ESC Extension Type (EET) octets, 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
       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.

    Chakrabarti, et al.          Standards Track                    [Page 4]

    RFC 8066            6LoWPAN ESC Dispatch Code Points       February 2017

    3.2.  ESC Extension Octets Typical Sequence

       The sequence and order of ESC extension octets with respect to the
       6LoWPAN Mesh header and LOWPAN_IPHC header are described below.  When
       the LOWPAN_IPHC dispatch type is present, ESC dispatch types MUST
       appear before the LOWPAN_IPHC dispatch type in order to maintain
       backward compatibility with Section 3.2 of RFC 6282.  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.          Standards Track                    [Page 5]

    RFC 8066            6LoWPAN ESC Dispatch Code Points       February 2017

    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] (see Section 9.4.2.3) defines commands that 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 Section 5.1 of RFC 4944 [RFC4944], 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

       IANA has registered the 'ESC Extension Types' 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.

       Section 4.1 of [RFC5226] 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
       of ESC Dispatch Octets" (Section 3) and the typical example
       (Section 3.2) sections.  ESC Extension Type code points MUST be used
       in conjunction with 6lo protocols following [RFC4944] or its

    Chakrabarti, et al.          Standards Track                    [Page 6]

    RFC 8066            6LoWPAN ESC Dispatch Code Points       February 2017

       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 as
       follows:

       +-------+---------------------------------+---------------+
       | Value | Description                     | Reference     |
       +-------+---------------------------------+---------------+
       |  0    | Reserved                        | 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                      |               |
       |       |                                 |               |
       | 255   | Reserved                        | This document |
       +-------+---------------------------------+---------------+

           Figure 4: Initial Values for the ESC Extension Types 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.  References

    6.1.  Normative References

       [Err4359]  RFC Errata, Erratum ID 4359, RFC 4944,
                  <https://www.rfc-editor.org/errata_search.php?eid=4359>.

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

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

    Chakrabarti, et al.          Standards Track                    [Page 7]

    RFC 8066            6LoWPAN ESC Dispatch Code Points       February 2017

       [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,
                  <http://www.rfc-editor.org/info/rfc6282>.

    6.2.  Informative References

       [G3-PLC]   International Telecommunications Union, "G.9903 :
                  Narrowband orthogonal frequency division multiplexing
                  power line communication transceivers for G3-PLC
                  networks", February 2014,
                  <http://www.itu.int/rec/T-REC-G.9903-201402-I>.

       [IANA-6LoWPAN]
                  IANA, "IPv6 Low Power Personal Area Network Parameters",
                  <https://www.iana.org/assignments/_6lowpan-parameters>.

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

    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, and 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.          Standards Track                    [Page 8]

    RFC 8066            6LoWPAN ESC Dispatch Code Points       February 2017

    Authors' Addresses

       Samita Chakrabarti
       San Jose, CA
       United States of America

       Email: samitac.ietf@gmail.com

       Gabriel Montenegro
       Microsoft
       United States of America

       Email: gabriel.montenegro@microsoft.com

       Ralph Droms
       United States of America

       Email: rdroms.ietf@gmail.com

       James Woodyatt
       Google
       Mountain View, CA
       United States of America

       Email: jhw@google.com

    Chakrabarti, et al.          Standards Track                    [Page 9]