Dear Carles, Thank you for the valuable comments.
I addressed all of them and attached the *diff* file for your and the WG's reference. Regards, Adnan & Tommaso On Tue, Oct 13, 2026 at 1:31 PM Carles Gomez Montenegro < [email protected]> wrote: > 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] >> > -- Regards, Adnan Rashid
<<< text/html; charset="UTF-8"; name="Carles Comments.6lowpan-over-Ethernet.diff.html": Unrecognized >>>
_______________________________________________ 6lo mailing list -- [email protected] To unsubscribe send an email to [email protected]
