IPv6 over Low-Power Wireless Personal Area Network (6LoWPAN) ESC Dispatch Code Points and Guidelines
updates
Extracted elements (17)
Multiple ESC dispatch types MAY appear in a 6LoWPAN header, though this is not desirable. Placing an EET toward the front of the packet increases the probability of the packet being dropped by legacy devices that don't understand it; placing it later allows legacy devices to process recognized dispatch types before encountering the unknown EET.
NALP dispatch codes only provide an escape method for non-6LoWPAN payloads when they appear as the initial octet of a LoWPAN encapsulation. ESC dispatch types are orthogonal to NALP octets since ESC is part of the 6LoWPAN extended dispatch space.
Erratum ID 4359 on RFC 4944 corrects Section 5.1 to indicate that the Extension Type field may contain additional dispatch values larger than 63. This document references that erratum as normative.
Existing RFC 4944 implementations are not expected to be capable of processing ESC extension data octets as defined in this document. Such implementations will likely drop the packet or ignore the ESC dispatch octets when encountering an unknown EET.
ITU-T G.9903 (G3-PLC) uses ESC dispatch type with Command IDs 0x01 to 0x1F for native mesh routing and bootstrapping. The G.9903 frame format uses the ESC octet followed by a Command ID and Command Payload.
A router node SHOULD forward a 6LoWPAN packet with EET octets as long as it does not attempt to process any unknown ESC extension octets, enabling transit routing without full ESC support.
ESC Extension Type code points MUST be used in conjunction with 6lo protocols following RFC 4944 or its derivatives, and the requesting document MUST specify how ESC dispatch octets will be used along with 6LoWPAN headers.
For each ESC Extension Type (except 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.
If an implementation reaches an ESC dispatch type for which it does not understand the ESC Extension Type (EET) octets, it MUST drop that packet.
Specifications of extension octets MUST NOT redefine existing ESC Extension Type codes, ensuring backward compatibility and interoperability across implementations.
The new dispatch type (EET) MUST NOT modify the behavior of existing dispatch types defined in RFC 4944, preserving backward compatibility.
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 RFC 6282 Section 3.2.
ESC extension types and 6LoWPAN dispatch values use orthogonal code spaces — EET values are similar to dispatch values but are preceded by the ESC dispatch type, so they do not collide with the standard dispatch value space.
The ESC dispatch type (value '01000000') is followed by an ESC Extension Type (EET) octet (values 0-255), then an Extended Dispatch Payload (EDP) whose format is defined by the EET. Values 0 and 255 are reserved; values 1-254 are IANA-assigned.
This document creates the 'ESC Extension Types' IANA registry with policy 'Specification Required'. Initial values: 0 (Reserved), 1-31 (ITU-T G.9903 and G.9905 Command IDs), 32-254 (Unassigned), 255 (Reserved). Each registered EET must have a specification defining the corresponding Extended Dispatch Payload frame octets.
There are no additional security threats due to the assignments of ESC dispatch type usage described in this document. The document forbids defining any extended dispatch values or extension types that modify the behavior of existing dispatch types, which prevents potential security issues from behavioral redefinition.
The ESC frame format is: ESC dispatch octet (1 byte, '01000000') | ESC Extension Type (1 byte) | Extended Dispatch Payload (variable, defined per EET). This structure extends the 6LoWPAN dispatch header beyond the original 6-bit dispatch value space.