| Internet-Draft | 6LoWPAN-PLH | August 2026 |
| Rashid & Pecorella | Expires 22 February 2027 | [Page] |
6LoWPAN compression schemes, including HC1 [RFC4944], IPHC [RFC6282], and GHC [RFC7400], elide the IPv6 Payload Length (PL) field from compressed packets, relying on the Layer 2 (L2) PL to reconstruct it at the receiver. This assumption holds for IEEE 802.15.4 [IEEE Std 802.15.4], which delivers exactly the bytes transmitted. However, L2 technologies that enforce a minimum frame size — most notably Ethernet IEEE 802.3 [IEEE Std 802.3], which has a minimum payload of 46 bytes — silently pad short frames with zero bytes. In such cases, the receiver incorrectly reconstructs the IPv6 PL field, leading to packet corruption and protocol failure. This document describes the problem, analyzes existing workarounds, and defines a solution based on an Escape dispatch byte (ESC) or ESC Extension Type (EET) extended dispatch mechanism that explicitly encodes the IPv6 PL when L2 padding may be present.¶
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 https://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 22 February 2027.¶
Copyright (c) 2026 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 (https://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 Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶
The 6LoWPAN adaptation layer defines several compression schemes, i.e., HC1 [RFC4944], IPHC [RFC6282], and GHC [RFC7400]. In all these schemes, the IPv6 PL is elided, and the 6LoWPAN compressed PL is derived from the L2 PL.¶
This idea is valid when the underlying L2 technology faithfully preserves the exact number of bytes transmitted, as is the case with IEEE 802.15.4 [IEEE Std 802.15.4].¶
However, 6LoWPAN is increasingly deployed over other L2 technologies, including Ethernet IEEE 802.3 [IEEE Std 802.3], to which an EtherType (0xA0ED) has been assigned [RFC7973]. Ethernet enforces a minimum frame payload size of 46 bytes (or 42 bytes with 802.1Q VLAN tagging). When the actual payload is shorter than this minimum, Ethernet silently appends zero padding bytes to reach the minimum length. The receiver has no mechanism to distinguish real payload bytes from padding bytes.¶
This creates a correctness failure: decompression may fail, or the receiver may reconstruct an IPv6 PL that is larger than the original payload. Both outcomes are undesirable.¶
This document describes the problem statement, evaluates existing mitigations, and defines a normative solution using the ESC/EET extended dispatch mechanism [RFC8025] to explicitly signal the IPv6 PL when L2 padding may be present.¶
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶
This document uses terms and concepts that are discussed in:¶
This document uses the following terms:¶
6LoWPAN: IPv6 over Low-Power Wireless Personal Area Networks, as defined in [RFC4944] and extended by [RFC6282], [RFC7400], and related documents.¶
HC1: Header Compression, as defined in [RFC4944].¶
IPHC: IPv6 Header Compression, as defined in [RFC6282].¶
GHC: Generic Header Compression, as defined in [RFC7400].¶
Layer 2 minimum frame size: The minimum number of bytes that a L2 technology requires in the payload field of a frame. Frames shorter than this minimum are padded by the L2 implementation.¶
Layer 2 padding: Zero bytes appended by a L2 technology to a frame payload to reach the L2 minimum frame size. L2 padding is transparent to higher layers unless explicitly signalled.¶
ESC: The 6LoWPAN Escape dispatch byte (0x7F), as defined in [RFC8025], used to introduce extended dispatch types.¶
EET: ESC Extension Type. The byte following an ESC dispatch byte that identifies the specific extended dispatch mechanism in use.¶
LOWPAN_EPLH: Explicit Payload Length Header. The new ESC Extension Type defined in this document.¶
This section describes the problem that arises when 6LoWPAN elides the IPv6 PL field and the underlying L2 technology pads frames to a minimum payload size.¶
Sections 10.1 of [RFC4944] and 3.1.1 of [RFC6282] specify that the IPv6 PL field is always elided.¶
Datagrams that are fragmented by 6LoWPAN have their size in the FRAG1 or FRAGN dispatches, but unfragmented datagrams do not carry information about the IPv6 PL, relying on the L2 payload size.¶
The receiver reconstructs the IPv6 PL field using the following formula:¶
IPv6 PL = L2 PL - 6LoWPAN compressed header length
This is valid when L2 PL equals the number of bytes placed on the wire by the sender — i.e., when L2 does not modify the payload.¶
Ethernet [IEEE Std 802.3] requires a minimum frame payload of 46 bytes (without 802.1Q) or 42 bytes (with 802.1Q VLAN tagging). When the frame payload is shorter than this minimum, the Ethernet hardware or driver appends zero-value (0x00) padding bytes silently. These padding bytes are indistinguishable from payload bytes at the receiver.¶
Other L2 technologies may impose similar minimum frame size requirements, including but not limited to:¶
Note: IEEE 802.15.4 does NOT impose a minimum frame payload size and is therefore NOT affected by this problem.¶
The failure occurs when all three of the following conditions are simultaneously true:¶
When all three conditions hold, the following sequence occurs:¶
IPv6 PL = L2_minimum - header_bytes
This reconstructed length is INCORRECT.¶
Furthermore, when using GHC compression, the decompressor also considers the padding bytes part of the compressed datagram, and decompression might fail, depending on the decompression code and the value of the padding bytes.¶
If the GHC decompression does not fail, or if the scheme is HC1 [RFC4944] or IPHC [RFC6282], the receiver passes an IPv6 PL that is (L2_minimum - N) bytes larger than the true PL to upper-layer protocol parsers.¶
Upper-layer parsers (UDP, TCP, ICMP, CoAP, etc.) attempt to process padding bytes as protocol data, leading to checksum failures, malformed packets, or silent data corruption.¶
Example:¶
Compressed 6LoWPAN packet: IPHC dispatch = 2 bytes Compressed UDP = 1 byte (NHC) CoAP payload = 8 bytes Total = 11 bytes Ethernet minimum payload = 46 bytes Ethernet padding added = 35 bytes (0x00) Receiver reconstruction: L2 Payload Length = 46 bytes (observed) IPHC header = 2 bytes Reconstructed IPv6 PL = 44 bytes (INCORRECT) Actual IPv6 PL = 9 bytes (CORRECT) Excess bytes fed upward = 35 bytes (padding)
The following specifications are affected by this problem, as they all rely on L2 PL to reconstruct the IPv6 PL field:¶
[RFC7973] assigns an EtherType for 6LoWPAN over Ethernet but does not address this padding problem. Consequently, the specification serves as a prerequisite for the problem but not a solution to it.¶
Using the 6LoWPAN uncompressed IPv6 dispatch (0x41) sends the full 40 bytes IPv6 header without compression, preserving the PLfield. This eliminates the ambiguity but defeats the purpose of 6LoWPAN compression. For very short payloads — exactly the packets most likely to trigger the padding problem — the overhead of the full IPv6 header is disproportionate.¶
This approach requires knowledge of the L2 minimum frame size at the 6LoWPAN layer.¶
This approach is acknowledged as a valid short-term workaround for networks that do not have an EtherType (or equivalent), but it does not constitute a complete solution.¶
An implementation may choose not to use 6LoWPAN compression for packets shorter than the L2 minimum frame size, instead sending them as uncompressed IPv6. Since Ethernet has an EtherType field, IPv6 (EtherType 0x86DD) and 6LoWPAN (EtherType 0xA0ED) can coexist on the same link.¶
While technically viable, this approach:¶
This approach is acknowledged as a valid short-term workaround for networks that have an EtherType (or equivalent), but it does not constitute a complete solution.¶
[RFC7400] permits (but does not mandate) the use of a stop code to terminate GHC-compressed data. Mandating the stop code when L2 padding is present would allow receivers to identify the end of real data.¶
Amending the RFC to mandate the use of a stop code in the case of padded data would work for GHC compression, but it is not a valid solution for HC1 [RFC4944] and IPHC [RFC6282], as the stop code value may legitimately appear within upper-layer payload data (e.g., within ICMP or UDP payloads). A receiver would be unable to distinguish a stop code embedded in payload data from a genuine terminator, leading to incorrect early termination of payload parsing.¶
This approach is NOT RECOMMENDED because it is not applicable to HC1 or IPHC and would require an amendment to the GHC specification [RFC7400].¶
This section defines an ESC/EET-based explicit PLmechanism to avoid ambiguity introduced by L2 padding.¶
RFC 8025 [RFC8025] defines the ESC dispatch byte (0x7F) for 6LoWPAN, which introduces a two-byte extended dispatch mechanism. The byte following ESC is the ESC Extension Type (EET), which identifies the specific extended dispatch in use. This mechanism was designed to extend the 6LoWPAN dispatch namespace without breaking existing implementations: a receiver that does not understand an EET value will recognize the ESC byte and handle the packet appropriately (for example, discard it), rather than silently misinterpreting it.¶
This document defines a new ESC Extension Type (EET) value, to be designated Explicit Payload Length Header (LOWPAN_EPLH) and assigned by IANA from the ESC Extension Type registry.¶
The LOWPAN_EPLH EET signals that the next byte in the 6LoWPAN frame explicitly encodes the IPv6 PL, allowing the receiver to correctly reconstruct it independently of the L2 Payload Length.¶
A 6LoWPAN frame using LOWPAN_EPLH has the following format:¶
0 1 2 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ESC (0x7F) | LOWPAN_EPLH | IPv6 PL (1B) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + 6LoWPAN compressed packet (IPHC/GHC) + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + L2 padding (ignored) (variable) + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Fields in the LOWPAN_EPLH format:¶
ESC (1 byte): The 6LoWPAN Escape dispatch byte, value 0x7F, as defined in [RFC8025].¶
LOWPAN_EPLH (1 byte): The ESC Extension Type value assigned by IANA for Explicit Payload Length Header (EPLH) (this document).¶
IPv6 PL (1 byte): The explicit IPv6 PL, encoded as an 8-bit unsigned integer. This value represents the total number of bytes following the IPv6 header (i.e., the IPv6 PL as defined in [RFC8200]).¶
An 8-bit field is sufficient because the problem only arises for packets shorter than the L2 minimum frame size (46 bytes for Ethernet). The maximum possible IPv6 PL for an affected packet is bounded by the L2 minimum frame size minus the minimum 6LoWPAN header size, which is well within the range of an 8-bit unsigned integer (0-255).¶
6LoWPAN compressed packet: The IPHC, HC1, or GHC compressed packet, formatted as defined in [RFC6282] or [RFC7400], respectively. The compressed packet immediately follows the LOWPAN_EPLH header.¶
L2 padding: Zero or more padding bytes appended by the L2 layer. These bytes MUST be ignored by the receiver.¶
A sender MUST use the LOWPAN_EPLH header when all of the following conditions are true:¶
a) 6LoWPAN header compression (HC1, IPHC, or GHC) is used for the packet, causing the IPv6 PL field to be elided.¶
b) The L2 technology in use enforces a minimum frame payload size (e.g., Ethernet, with a minimum payload of 46 bytes).¶
c) The total length of the 6LoWPAN compressed packet (including all compressed headers) is less than the L2 minimum frame payload size.¶
A sender MAY use the LOWPAN_EPLH header in other cases (e.g., as a precautionary measure) when conditions (a) and (b) are met, regardless of packet length.¶
A sender MUST NOT use the LOWPAN_EPLH header on L2 technologies that do not add padding (e.g., IEEE 802.15.4), as this would add unnecessary overhead.¶
The IPv6 PL field MUST be set to the true IPv6 PL of the packet, as defined in [RFC8200], before compression is applied.¶
The total overhead introduced by the LOWPAN_EPLH mechanism is 3 bytes (1 byte ESC + 1 byte EET + 1 byte length).¶
A receiver that encounters an ESC dispatch byte (0x7F) MUST read the following byte as the EET value.¶
If the EET value matches LOWPAN_EPLH (as assigned by IANA):¶
a) The receiver MUST read the following byte as the explicit IPv6 PL.¶
b) The receiver MUST use this explicit value as the IPv6 PL when decompressing and reassembling the IPv6 packet. The receiver MUST NOT use the L2 PL for this purpose.¶
c) The receiver MUST process exactly IPv6_PL bytes of payload from the 6LoWPAN compressed packet following the LOWPAN_EPLH header.¶
d) Any bytes beyond the explicit PL and before the end of the L2 frame MUST be treated as L2 padding and MUST be discarded.¶
A receiver that does not recognize the LOWPAN_EPLH EET value SHOULD discard the packet and MAY log an error.¶
The LOWPAN_EPLH mechanism introduces 3 bytes of overhead:¶
ESC byte = 1 byte¶
LOWPAN_EPLH EET = 1 byte¶
IPv6 PL field = 1 byte¶
Total overhead = 3 bytes¶
This overhead is only incurred for packets shorter than the L2 minimum frame size. For Ethernet, this means packets where the compressed 6LoWPAN data is under 46 bytes. Such packets are by definition very short — typically ICMP echo requests, CoAP confirmable messages, or keepalive traffic. The 3 bytes overhead will likely not increase the payload size above the minimum L2 payload size, with the notable exception of datagrams whose length is exactly one or 2 bytes less than said minimum payload size. In this case, the overhead is exactly two or 1bytes, respectively. Thus, we can assume that the overhead is negligible.¶
Although this document uses Ethernet as the primary example, the LOWPAN_EPLH mechanism is applicable to any L2 technology that enforces a minimum frame payload size that may cause padding of short 6LoWPAN frames.¶
Implementations SHOULD apply the LOWPAN_EPLH mechanism whenever this condition applies, regardless of the specific L2 technology in use.¶
IEEE 802.15.4 networks are automatically excluded from the MUST use requirement in Section 7.4, as IEEE 802.15.4 does not impose a minimum frame payload size.¶
The LOWPAN_EPLH mechanism introduces an explicit length field into the 6LoWPAN frame. The following security considerations apply.¶
An attacker who can modify L2 frames in transit could manipulate the IPv6 PL field to cause the receiver to read fewer bytes than the actual payload (truncation attack) or to read into padding bytes (confusion attack). These threats are mitigated by link-layer security mechanisms (e.g., IEEE 802.15.4 security, MACsec for Ethernet) and by upper-layer integrity checks (e.g., UDP/TCP checksums, DTLS, etc.).¶
The LOWPAN_EPLH mechanism does not introduce new cryptographic vulnerabilities. Its security properties are consistent with those of the underlying 6LoWPAN compression framework [RFC6282].¶
Receivers MUST validate that the explicit IPv6 PL is consistent with the L2 frame length (i.e., the explicit length MUST NOT exceed the actual number of bytes remaining in the L2 payload after the LOWPAN_EPLH header). Inconsistent values SHOULD result in the packet being discarded.¶
This document requests that IANA assign a new ESC Extension Type (EET) value from the "ESC Extension Types" registry established by [RFC8025]:¶
Value: [to be assigned by IANA]¶
Name: LOWPAN_EPLH¶
Description: Explicit IPv6 PL Header for 6LoWPAN compression over L2 technologies with minimum frame size requirements¶
Reference: [this document]¶
The assigned value MUST be used in the EET field as defined in Section 7 of this document.¶