6lo
Internet Engineering Task Force (IETF)                    S. Chakrabarti
Internet-Draft
Request for Comments: 8066
Updates: 4944, 6282 (if approved)                                        G. Montenegro
Intended status:
Category: Standards Track                                      Microsoft
Expires: June 11, 2017
ISSN: 2070-1721                                                 R. Droms

                                                             J. Woodyatt
                                                                  Google
                                                        December 8, 2016

            6lowpan
                                                           February 2017

      IPv6 over Low-Power Wireless Personal Area Network (6LoWPAN)
                ESC Dispatch Code Points and Guidelines
                draft-ietf-6lo-dispatch-iana-registry-07

Abstract

   RFC4944

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

Status of this This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents an Internet Standards Track document.

   This document is a product of the Internet Engineering Task Force
   (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list  It represents the consensus of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid the IETF community.  It has
   received public review and has been approved for a maximum 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 six months this document, any errata,
   and how to provide feedback on it may be updated, replaced, or obsoleted by other documents obtained 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.
   http://www.rfc-editor.org/info/rfc8066.

Copyright Notice

   Copyright (c) 2016 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
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3   2
   3.  Usage of ESC dispatch octets  . Dispatch Octets  . . . . . . . . . . . . . . . .   3
     3.1.  Interaction with other RFC4944 implementations  . Other RFC 4944 Implementations . . . . .   4
     3.2.  ESC Extension Octets Typical Sequence . . . . . . . . . . . 5   4
     3.3.  ITU-T G.9903 ESC type usage Type Usage . . . . . . . . . . . . . . . 6   5
     3.4.  NALP and ESC dispatch types . Dispatch Types . . . . . . . . . . . . . . .   6
   4.  IANA Considerations . . . . . . . . . . . . . . . . . . . . . .   6
   5.  Security Considerations . . . . . . . . . . . . . . . . . . . .   7
   6.  Acknowledgements  . .  References  . . . . . . . . . . . . . . . . . . . . . 7
   7.  References . . . .   7
     6.1.  Normative References  . . . . . . . . . . . . . . . . . .   7
     6.2.  Informative References  . . . . 8
     7.1.  Normative References . . . . . . . . . . . . .   8
   Acknowledgements  . . . . . . 8
     7.2.  Informative References . . . . . . . . . . . . . . . . . .   8
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . . .   8

1.  Introduction

   [RFC4944] section

   Section 5.1 of [RFC4944] defines the dispatch header and types.  The
   ESC type is defined for using to use additional dispatch octets in the 6lowpan 6LoWPAN
   header.  RFC 6282 modifies the value of the ESC dispatch type and
   that value is recorded in IANA registry [6LOWPAN-IANA]. [IANA-6LoWPAN].  However, the
   octets and usage following the ESC dispatch type are not defined in
   either [RFC4944] and or [RFC6282].  In recent years with 6lowpan 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

   This document defines the ITU-T specification for ESC
   dispatch octet code points as an existing known usage new "ESC Extension Types" registry and propose the
   definition of
   ESC extension octets for future applications.  The  In addition, this
   document also requests IANA actions for the first extension octet
   following records the ITU-T specification for ESC dispatch type. 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 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 Dispatch Type

   ESC: The left-most octet is the ESC dispatch type containing
   '01000000'
   '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 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 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 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 in RFC4944 of RFC 4944 indicates that the Extension Type field may
   contain additional dispatch values larger than 63, as corrected by
   [4944-ERRATA].
   [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 RFC4944 implementations Other RFC 4944 Implementations

   It is expected that existing implementations of RFC4944 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 attempt 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 packet, reaches an ESC dispatch type for which it does
   not understand the extension octets (EET), it MUST ESC Extension Type (EET) octets, it MUST drop that
   packet.  However, it is important to clarify that a router node
   SHOULD forward a 6lowpan 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 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.

3.2.  ESC Extension Octets Typical Sequence

   ESC Extension octets

   The sequence and order of ESC extension octets with respect to the
   6LoWPAN Mesh header and LoWPAN_IPHC 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 RFC6282 section 3.2. 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 6LoWPAN Packet with ESC dispatch types Dispatch Types

3.3.  ITU-T G.9903 ESC type usage 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 (see Section 9.4.2.3) defines commands which that are formatted
   like ESC Extension type 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 Dispatch Type

3.4.  NALP and ESC dispatch types Dispatch Types

   According to RFC4944 [RFC4944] section 5.1, 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
   non-6LoWPAN payloads.  Since ESC dispatch types are part of 6lowpan 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 has registered the 'ESC Extension Type' 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) 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

   Section 4.1 also 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" Dispatch Octets" (Section 3) and the typical example
   (Section 3.2) sections.  ESC Extension type 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 6LoWPAN headers in their use
   cases.

   The initial values for the 'ESC Extension Type' fields are: are as
   follows:

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

   This document was produced using the xml2rfc tool.

7.  References

7.1.

6.1.  Normative References

   [4944-ERRATA]
              "https://www.rfc-editor.org/errata_search.php?rfc=4944".

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

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

7.2.

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

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