IPv6 over Low-Power Wireless Personal Area Network (6LoWPAN) ESC Dispatch Code Points and Guidelines
Gives the 6LoWPAN escape dispatch type a defined layout and a registry for the extensions that use it.
Chakrabarti, S., Montenegro, G., Droms, R., and J. Woodyatt, "IPv6 over Low-Power Wireless Personal Area Network (6LoWPAN) ESC Dispatch Code Points and Guidelines", RFC 8066, DOI 10.17487/RFC8066, February 2017, <https://www.rfc-editor.org/info/rfc8066>.
@misc{rfc8066,
series = {Request for Comments},
number = 8066,
howpublished = {RFC 8066},
publisher = {RFC Editor},
doi = {10.17487/RFC8066},
url = {https://www.rfc-editor.org/info/rfc8066},
author = {S. Chakrabarti and G. Montenegro and R. Droms and J. Woodyatt},
title = {{IPv6 over Low-Power Wireless Personal Area Network (6LoWPAN) ESC Dispatch Code Points and Guidelines}},
pagetotal = 9,
year = 2017,
month = feb,
} RFC text
Contents
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.
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
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
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.
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
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
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>.
[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.
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
AI ELI5
On this page
§1The Undefined Escape Hatch
Section 5.1 of RFC 4944 defines the 6LoWPAN dispatch header and its types. One of them, the ESC type, exists so that additional dispatch octets can follow in the header. RFC 6282 changed the value of the ESC dispatch type, and IANA recorded that value.
What neither RFC defined was the octets that come after ESC or how to use them. Meanwhile, implementations and standards bodies had started using those octets. This document updates both RFCs by defining the extension octet code points and creating a new "ESC Extension Types" registry, and it records one existing use from ITU-T.
There was a door marked ESC for extra features, but no sign saying what was behind it. People started walking through anyway, so this RFC writes the sign.
§2The ESC Frame Format
The ESC dispatch type is the left-most octet and holds 01000000. The first octet after it is the ESC Extension Type (EET). It selects which extension is in use. Everything after the EET is the Extended Dispatch Payload (EDP), and the extension itself decides how the EDP is laid out.
EET values run from 0 to 255. Values 0 and 255 are reserved for future use, and IANA assigns 1 to 254. EET values behave like dispatch values but come after the ESC type, so the two use orthogonal code spaces. Multiple ESC dispatch types MAY appear in one 6LoWPAN header, though the RFC calls that not desirable.
Each extension type needs a specification that defines its payload. Such specifications MUST NOT redefine existing EET codes, and a new EET MUST NOT modify the behavior of existing dispatch types from RFC 4944.
After the ESC door comes a number saying which extra feature you want. Whatever follows that number belongs to that feature. Nobody may reuse a number or change what the old doors do.
§3Unknown Extensions and Older Nodes
Existing RFC 4944 implementations cannot process ESC extension data. The RFC expects that such a node will drop the packet or ignore the ESC dispatch octets when it meets an EET it does not know.
An implementation that follows this document MUST drop a packet when it reaches an EET it does not understand. A router node SHOULD still forward a 6LoWPAN packet carrying EET octets, as long as it does not try to process the unknown extension.
Placement matters. ESC dispatch types can be first, last or in the middle. A node that does not understand the EET at the start of the packet drops it. Putting the EET later gives a legacy device a chance to recognize and handle an earlier dispatch type, and then ignore the EET instead of dropping the whole packet.
If you find a door you do not understand, a new-style node throws the packet away, but a router may still pass it along unopened. Putting the strange door near the back means older nodes can read the front part first.
§4Where ESC Goes in a Packet
When a LOWPAN_IPHC dispatch type is present, ESC dispatch types MUST appear before it, to stay backward compatible with Section 3.2 of RFC 6282. The RFC shows several typical orderings:
- ESC, EET, EDP, then the dispatch, the
LOWPAN_IPHCheader and the payload. - A mesh header, then ESC, EET and EDP, then the dispatch and
LOWPAN_IPHCheader. - A mesh header followed by ESC, EET and EDP alone.
- A mesh header and fragment header followed by ESC, EET and EDP.
- ESC, EET and EDP as the whole 6LoWPAN encapsulation.
One known user is ITU-T G.9903 (G3-PLC), which uses the ESC dispatch type for native mesh routing and bootstrapping. Its command IDs are formatted like EET fields and run from 0x01 to 0x1F.
The RFC also clarifies NALP dispatch codes, which mark non-6LoWPAN payloads. They only provide that escape when they are the initial octet of a LoWPAN encapsulation. Their meaning anywhere else is reserved for future use, and ESC types are orthogonal to them.
The ESC piece can sit in different spots in the packet, but if there is a compressed IPv6 header, ESC must come first. One power-line system already uses it for its own commands.
§5The ESC Extension Types Registry
IANA registered the "ESC Extension Types" values under the Specification Required policy, the same policy as in RFC 4944. A Designated Expert reviews the public specification that requests a value. Each specification MUST define the Extended Dispatch Payload octets so receivers can read the ESC types interoperably, and it MUST say how the ESC octets are used with 6LoWPAN headers.
The code points MUST be used with 6lo protocols that follow RFC 4944 or its derivatives. The initial registry holds value 0 and 255 as reserved, values 1 to 31 for ITU-T G.9903 and G.9905 command IDs, and 32 to 254 unassigned.
To get a number, you write a public document explaining your feature, and an expert checks it. At the start, a few numbers are saved for a power-line standard and the rest are free.
- 0Reserved — Reserved by this document.
- 1-31ITU-T G.9903 and G.9905 — Used as command IDs.
- 32-254Unassigned — Available through Specification Required.
- 255Reserved — Reserved by this document.
§6Security Considerations
The RFC says there are no additional security threats from the ESC dispatch assignments it describes. It also forbids defining any extended dispatch values or extension types that modify the behavior of existing dispatch types, which keeps new extensions from changing how current header types are treated.
Adding a labeled door adds no new danger, and the rules say new doors may not change how old ones work.