6lo A. Rashid Internet-Draft Intended status: Standards Track T. Pecorella Expires: 22 February 2027 University of Florence 21 August 2026 6LoWPAN Payload Length Handling with L2 Padding draft-rashid-pecorella-6lo-lowpan-padding-length-00 Abstract 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. Status of This Memo 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 Notice Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved. Rashid & Pecorella Expires 22 February 2027 [Page 1] Internet-Draft 6LoWPAN-PLH August 2026 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. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 2.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 2.2. References . . . . . . . . . . . . . . . . . . . . . . . 3 3. Terms and Definitions . . . . . . . . . . . . . . . . . . . . 4 4. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 4 4.1. 6LoWPAN Payload Length Elision . . . . . . . . . . . . . 4 4.2. L2 Minimum Frame Size Padding . . . . . . . . . . . . . . 5 4.3. Failure Scenario . . . . . . . . . . . . . . . . . . . . 5 5. Affected Specifications . . . . . . . . . . . . . . . . . . . 6 6. Existing Mitigations and Their Limitations . . . . . . . . . 7 6.1. Uncompressed IPv6 Dispatch . . . . . . . . . . . . . . . 7 6.2. Restricting 6LoWPAN to Packets Longer than L2 Minimum . . 7 6.3. Stop Code (GHC) . . . . . . . . . . . . . . . . . . . . . 8 7. Proposed Solution: ESC/EET Explicit Payload Length . . . . . 8 7.1. ESC/EET Mechanism Overview . . . . . . . . . . . . . . . 8 7.2. New EET Definition: Explicit IPv6 PL (LOWPAN_EPLH) . . . 8 7.3. Packet Format . . . . . . . . . . . . . . . . . . . . . . 9 7.4. Sender Behaviour . . . . . . . . . . . . . . . . . . . . 10 7.5. Receiver Behaviour . . . . . . . . . . . . . . . . . . . 10 7.6. Overhead Analysis . . . . . . . . . . . . . . . . . . . . 11 8. Applicability to Other L2 Technologies . . . . . . . . . . . 11 9. Security Considerations . . . . . . . . . . . . . . . . . . . 11 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 11. Normative References . . . . . . . . . . . . . . . . . . . . 12 12. Informative References . . . . . . . . . . . . . . . . . . . 13 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 1. Introduction 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. Rashid & Pecorella Expires 22 February 2027 [Page 2] Internet-Draft 6LoWPAN-PLH August 2026 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. 2. Terminology 2.1. 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 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. 2.2. References This document uses terms and concepts that are discussed in: * Transmission of IPv6 Packets over IEEE 802.15.4 Networks [RFC4944], * Compression Format for IPv6 Datagrams over IEEE 802.15.4-Based Networks [RFC6282], * Generic Header Compression for IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs) [RFC7400] Rashid & Pecorella Expires 22 February 2027 [Page 3] Internet-Draft 6LoWPAN-PLH August 2026 3. Terms and Definitions 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. 4. 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. 4.1. 6LoWPAN Payload Length Elision 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: Rashid & Pecorella Expires 22 February 2027 [Page 4] Internet-Draft 6LoWPAN-PLH August 2026 IPv6 PL = L2 PL - 6LoWPAN compressed header length Figure 1: 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. 4.2. L2 Minimum Frame Size Padding 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: * 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. 4.3. Failure Scenario The failure occurs when all three of the following conditions are simultaneously true: 1. 6LoWPAN compression is used and elides the IPv6 PL field. 2. The L2 technology enforces a minimum frame payload size (e.g., Ethernet: 46 bytes). 3. The compressed 6LoWPAN packet is shorter than the L2 minimum frame payload. When all three conditions hold, the following sequence occurs: 1. The sender transmits a compressed 6LoWPAN packet of length N bytes, where N < L2_minimum. 2. The L2 pads the frame payload to L2_minimum bytes by appending (L2_minimum - N) zero bytes. Rashid & Pecorella Expires 22 February 2027 [Page 5] Internet-Draft 6LoWPAN-PLH August 2026 3. The receiver reads L2_minimum bytes as the L2 payload. 4. The receiver applies the reconstruction formula: IPv6 PL = L2_minimum - header_bytes Figure 2: 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 [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) Figure 3: Example Failure Scenario 5. Affected Specifications The following specifications are affected by this problem, as they all rely on L2 PL to reconstruct the IPv6 PL field: Rashid & Pecorella Expires 22 February 2027 [Page 6] Internet-Draft 6LoWPAN-PLH August 2026 * [RFC4944]: HC1 compression * [RFC6282]: IPHC compression (Section 3.1.1) * [RFC7400]: GHC compression * Any future 6LoWPAN compression scheme that elides 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. 6. Existing Mitigations and Their Limitations 6.1. 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. 6.2. 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. Rashid & Pecorella Expires 22 February 2027 [Page 7] Internet-Draft 6LoWPAN-PLH August 2026 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. 6.3. Stop Code (GHC) [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]. 7. Proposed Solution: ESC/EET Explicit Payload Length This section defines an ESC/EET-based explicit PLmechanism to avoid ambiguity introduced by L2 padding. 7.1. ESC/EET Mechanism Overview 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. 7.2. 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. Rashid & Pecorella Expires 22 February 2027 [Page 8] Internet-Draft 6LoWPAN-PLH August 2026 7.3. Packet Format 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) + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 4: LOWPAN_EPLH Format 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. Rashid & Pecorella Expires 22 February 2027 [Page 9] Internet-Draft 6LoWPAN-PLH August 2026 7.4. 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 [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). 7.5. 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. Rashid & Pecorella Expires 22 February 2027 [Page 10] Internet-Draft 6LoWPAN-PLH August 2026 A receiver that does not recognize the LOWPAN_EPLH EET value SHOULD discard the packet and MAY log an error. 7.6. 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. 8. 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. 9. 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 Rashid & Pecorella Expires 22 February 2027 [Page 11] Internet-Draft 6LoWPAN-PLH August 2026 (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. 10. IANA Considerations 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. 11. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [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, . Rashid & Pecorella Expires 22 February 2027 [Page 12] Internet-Draft 6LoWPAN-PLH August 2026 [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, . [RFC7400] Bormann, C., "6LoWPAN-GHC: Generic Header Compression for IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs)", RFC 7400, DOI 10.17487/RFC7400, November 2014, . [RFC7973] Droms, R. and P. Duffy, "Assignment of an Ethertype for IPv6 with Low-Power Wireless Personal Area Network (LoWPAN) Encapsulation", RFC 7973, DOI 10.17487/RFC7973, November 2016, . [RFC8025] Thubert, P., Ed. and R. Cragie, "IPv6 over Low-Power Wireless Personal Area Network (6LoWPAN) Paging Dispatch", RFC 8025, DOI 10.17487/RFC8025, November 2016, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", STD 86, RFC 8200, DOI 10.17487/RFC8200, July 2017, . 12. Informative References [IEEE Std 802.15.4] IEEE standard for Information Technology, "IEEE Std 802.15.4, Part. 15.4: Wireless Medium Access Control (MAC) and Physical Layer (PHY) Specifications for Low-Rate Wireless Personal Area Networks". [IEEE Std 802.3] IEEE, "IEEE Standard for Ethernet", IEEE Std 802.3, 2022. Authors' Addresses Adnan Rashid 70123 Bari Italy Email: adnanrashidpk@gmail.com Rashid & Pecorella Expires 22 February 2027 [Page 13] Internet-Draft 6LoWPAN-PLH August 2026 Tommaso Pecorella University of Florence Italy Email: tommaso.pecorella@unifi.it Rashid & Pecorella Expires 22 February 2027 [Page 14]