6LoWPAN Payload Length Handling with L2 Padding

Introduction The 6LoWPAN adaptation layer defines several compression schemes, i.e., HC1 , IPHC , and GHC . 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 . However, 6LoWPAN is increasingly deployed over other L2 technologies, including Ethernet IEEE 802.3 , to which an EtherType (0xA0ED) has been assigned . 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 to explicitly signal the IPv6 PL when L2 padding may be present.

Terminology

Requirements Language 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 when, and only when, they appear in all capitals, as shown here.

References This document uses terms and concepts that are discussed in:

Transmission of IPv6 Packets over IEEE 802.15.4 Networks,
Compression Format for IPv6 Datagrams over IEEE 802.15.4-Based Networks,
Generic Header Compression for IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs)

Terms and Definitions This document uses the following terms: 6LoWPAN: IPv6 over Low-Power Wireless Personal Area Networks, as defined in and extended by , , and related documents. HC1: Header Compression, as defined in . IPHC: IPv6 Header Compression, as defined in . GHC: Generic Header Compression, as defined in . 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 , 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.

Problem Statement 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.

6LoWPAN Payload Length Elision Sections 10.1 of and 3.1.1 of 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 Reconstruction Formula 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.

L2 Minimum Frame Size Padding Ethernet 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:

IEEE 802.11 (Wi-Fi) in certain configurations
Token Ring (historical)
Any other L2 technology with minimum payload constraints

Note: IEEE 802.15.4 does NOT impose a minimum frame payload size and is therefore NOT affected by this problem.

Failure Scenario The failure occurs when all three of the following conditions are simultaneously true:

6LoWPAN compression is used and elides the IPv6 PL field.
The L2 technology enforces a minimum frame payload size (e.g., Ethernet: 46 bytes).
The compressed 6LoWPAN packet is shorter than the L2 minimum frame payload.

When all three conditions hold, the following sequence occurs:

The sender transmits a compressed 6LoWPAN packet of length N bytes, where N < L2_minimum.
The L2 pads the frame payload to L2_minimum bytes by appending (L2_minimum - N) zero bytes.
The receiver reads L2_minimum bytes as the L2 payload.
The receiver applies the reconstruction formula:

Reconstructed IPv6 PL 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 or IPHC , 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:

Example Failure Scenario

Affected Specifications The following specifications are affected by this problem, as they all rely on L2 PL to reconstruct the IPv6 PL field:

: HC1 compression
: IPHC compression (Section 3.1.1)
: GHC compression
Any future 6LoWPAN compression scheme that elides the IPv6 PL field

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.

Existing Mitigations and Their Limitations

Uncompressed IPv6 Dispatch 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.

Restricting 6LoWPAN to Packets Longer than L2 Minimum 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:

Requires implementations to have knowledge of the L2 minimum frame size at the 6LoWPAN layer.
Does not apply to L2 technologies where IPv6 and 6LoWPAN cannot coexist via separate EtherTypes.

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.

Stop Code (GHC) 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 and IPHC , 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 .

Proposed Solution: ESC/EET Explicit Payload Length This section defines an ESC/EET-based explicit PLmechanism to avoid ambiguity introduced by L2 padding.

ESC/EET Mechanism Overview RFC 8025 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.

New EET Definition: Explicit IPv6 PL (LOWPAN_EPLH) 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.

Packet Format A 6LoWPAN frame using LOWPAN_EPLH has the following format:

LOWPAN_EPLH 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 . 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 ). 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 or , 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.

Sender Behaviour 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 , 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).

Receiver Behaviour 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.

Overhead Analysis 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.

Applicability to Other L2 Technologies 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.

Security Considerations 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 . 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.

IANA Considerations This document requests that IANA assign a new ESC Extension Type (EET) value from the "ESC Extension Types" registry established by : 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 of this document.