6LoWPAN Payload Length Handling with L2 Padding
draft-rashid-pecorella-6lo-lowpan-padding-length-01
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
| Document | Type | Active Internet-Draft (individual) | |
|---|---|---|---|
| Authors | Adnan Rashid , Tommaso Pecorella | ||
| Last updated | 2026-10-20 | ||
| RFC stream | (None) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-rashid-pecorella-6lo-lowpan-padding-length-01
6lo A. Rashid
Internet-Draft
Intended status: Standards Track T. Pecorella
Expires: 23 April 2027 University of Florence
20 October 2026
6LoWPAN Payload Length Handling with L2 Padding
draft-rashid-pecorella-6lo-lowpan-padding-length-01
Abstract
6LoWPAN compression schemes, including legacy HC1 [RFC4944], modern
IPHC [RFC6282], and GHC [RFC7400], elide the IPv6 Payload Length (PL)
field from compressed packets, relying on the Layer 2 (L2) Length of
the Data field 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 23 April 2027.
Rashid & Pecorella Expires 23 April 2027 [Page 1]
Internet-Draft 6LoWPAN-PLH October 2026
Copyright Notice
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.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
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 . . . . . . . . . . . . . . . . . . . 7
6. Existing Mitigations and Their Limitations . . . . . . . . . 7
6.1. Uncompressed IPv6 Dispatch . . . . . . . . . . . . . . . 7
6.2. Restricting 6LoWPAN to Packets Longer than L2 Minimum . . 8
6.3. Stop Code (GHC) . . . . . . . . . . . . . . . . . . . . . 8
7. Proposed Solution: ESC/EET Explicit Payload Length . . . . . 9
7.1. ESC/EET Mechanism Overview . . . . . . . . . . . . . . . 9
7.2. New EET Definition: Explicit IPv6 PL (LOWPAN_EPLH) . . . 9
7.3. Packet Format . . . . . . . . . . . . . . . . . . . . . . 9
7.4. Sender Behaviour . . . . . . . . . . . . . . . . . . . . 10
7.5. Receiver Behaviour . . . . . . . . . . . . . . . . . . . 11
7.6. Overhead Analysis . . . . . . . . . . . . . . . . . . . . 11
8. Applicability to Other L2 Technologies . . . . . . . . . . . 12
9. Security Considerations . . . . . . . . . . . . . . . . . . . 12
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
11. Normative References . . . . . . . . . . . . . . . . . . . . 13
12. Informative References . . . . . . . . . . . . . . . . . . . 14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14
Rashid & Pecorella Expires 23 April 2027 [Page 2]
Internet-Draft 6LoWPAN-PLH October 2026
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.
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],
Rashid & Pecorella Expires 23 April 2027 [Page 3]
Internet-Draft 6LoWPAN-PLH October 2026
* Generic Header Compression for IPv6 over Low-Power Wireless
Personal Area Networks (6LoWPANs) [RFC7400]
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] (now largely
superseded by IPHC [RFC6282], included here for historical
completeness).
*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:* RFC 4944 defined the ESC dispatch byte with value 0x7F.
Subsequently, RFC 6282 replaced the 0x7F value by 0x40 (01000000).
*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.
Rashid & Pecorella Expires 23 April 2027 [Page 4]
Internet-Draft 6LoWPAN-PLH October 2026
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 Length - 6LoWPAN compressed header length
Figure 1: IPv6 PL Reconstruction Formula
This is valid when L2 Length 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.
Rashid & Pecorella Expires 23 April 2027 [Page 5]
Internet-Draft 6LoWPAN-PLH October 2026
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.
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:
Rashid & Pecorella Expires 23 April 2027 [Page 6]
Internet-Draft 6LoWPAN-PLH October 2026
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 dispatch = 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 Length to reconstruct the IPv6 PL field:
* [RFC4944]: HC1 compression
* [RFC6282]: IPHC compression (Section 3.1.1)
* [RFC7400]: GHC compression
* Any future 6LoWPAN compression scheme that elides the IPv6 PL
field and reconstructs it from the L2 Length
[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.
Rashid & Pecorella Expires 23 April 2027 [Page 7]
Internet-Draft 6LoWPAN-PLH October 2026
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.
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] or 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].
Rashid & Pecorella Expires 23 April 2027 [Page 8]
Internet-Draft 6LoWPAN-PLH October 2026
7. Proposed Solution: ESC/EET Explicit Payload Length
This section defines an ESC/EET-based explicit PL mechanism 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.
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 (0x40) | 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:
Rashid & Pecorella Expires 23 April 2027 [Page 9]
Internet-Draft 6LoWPAN-PLH October 2026
*ESC (1 byte):* The 6LoWPAN Escape dispatch byte, value 0x40, 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 compressed packet (using legacy HC1,
IPHC, or GHC), 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.
7.4. Sender Behaviour
A sender MUST use the LOWPAN_EPLH header when all of the following
conditions are true:
a) 6LoWPAN header compression (legacy 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.
Rashid & Pecorella Expires 23 April 2027 [Page 10]
Internet-Draft 6LoWPAN-PLH October 2026
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 (0x40) 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 Length 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.
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
Rashid & Pecorella Expires 23 April 2027 [Page 11]
Internet-Draft 6LoWPAN-PLH October 2026
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 1 byte, 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
(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.
Rashid & Pecorella Expires 23 April 2027 [Page 12]
Internet-Draft 6LoWPAN-PLH October 2026
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,
<https://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,
<https://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,
<https://www.rfc-editor.org/info/rfc6282>.
[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, <https://www.rfc-editor.org/info/rfc7400>.
[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, <https://www.rfc-editor.org/info/rfc7973>.
Rashid & Pecorella Expires 23 April 2027 [Page 13]
Internet-Draft 6LoWPAN-PLH October 2026
[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,
<https://www.rfc-editor.org/info/rfc8025>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", STD 86, RFC 8200,
DOI 10.17487/RFC8200, July 2017,
<https://www.rfc-editor.org/info/rfc8200>.
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
Tommaso Pecorella
University of Florence
Italy
Email: tommaso.pecorella@unifi.it
Rashid & Pecorella Expires 23 April 2027 [Page 14]