Hi Adnan, Tommaso, First of all, thanks for writing and submitting this draft.
Please find below a few comments (as a WG participant). This draft describes a current issue and also proposes a solution. In my opinion, the draft is well motivated, and the solution is reasonable. While the draft is just a -00, the content appears to be already quite complete. Some more specific comments: - The draft mentions HC1 [RFC4944] in several places. I guess it probably does not hurt, but since HC1 was replaced by IPHC [RFC6282], I'm wondering to what extent there might still be any 6LoWPAN implementations using HC1 and not IPHC. - Section 3. "*ESC:* The 6LoWPAN Escape dispatch byte (0x7F), as defined in [RFC8025], used to introduce extended dispatch types." [Carles] RFC 4944 defined the ESC dispatch byte with value 0x7F. Subsequently, RFC 6282 replaced the 0x7F value by 0b01000000. - Section 4. Perhaps s/IPHC dispatch/IPHC format ? - Section 5. Perhaps not just "Any future 6LoWPAN compression scheme that elides the IPv6 PL field". For example, using SCHC might allow to elide the IPv6 PL field, at least in some cases, when there is a good match between the IPv6 PL field value and the corresponding field in a compression Rule. Note that SCHC (or any similar mechanism) does not necessarily rely on L2 PL to reconstruct the IPv6 PL field. Nits: - Section 7: s/PLmechanism/PL mechanism - Section 7.6: s/1bytes/1 byte I hope this helps! Cheers, Carles (as WG participant) On Sat, 22 Aug 2026 at 00:09, Adnan Rashid <[email protected]> wrote: > Hi 6Lo Working Group, > > We have posted a new individual draft: > draft-rashid-pecorella-6lo-lowpan-padding-length-00. > > Title: 6LoWPAN Payload Length Handling with L2 Padding > URL: > https://datatracker.ietf.org/doc/draft-rashid-pecorella-6lo-lowpan-padding-length/ > > Abstract: > 6LoWPAN compression schemes (HC1, IPHC, GHC) elide the IPv6 Payload > Length (PL) field, relying on the Layer 2 PL to reconstruct it at the > receiver. However, L2 technologies that enforce a minimum frame > size—such as Ethernet IEEE 802.3 with its 46-byte minimum payload—pad > short frames with zero bytes. This leads to incorrect IPv6 PL > reconstruction, packet corruption, and protocol failure. > > This document analyzes the issue and proposes a solution using an > Escape dispatch byte (ESC) or ESC Extension Type (EET) extended > dispatch mechanism to explicitly encode the IPv6 PL when L2 padding > may be present. > > We would appreciate any feedback, comments, or thoughts from the working > group. > > Best regards, > Adnan Rashid & Tommaso Pecorella > > _______________________________________________ > 6lo mailing list -- [email protected] > To unsubscribe send an email to [email protected] >
_______________________________________________ 6lo mailing list -- [email protected] To unsubscribe send an email to [email protected]
