> Date: Tue, 16 Feb 2010 13:04:53 -0800
> From: Owen Kirby <[email protected]>
>
> However, I suspect that this assumption is no longer true
> in the case of the draft header compression. Especially
> now that IPv6 extension headers can be compressed (what do
> we do if ROLL adds ~160 bytes of routing headers to a
> packet?).
Owen,
A long source route could quite possibly push the transport
header into the second fragment.
> [...] We get stuck in a catch-22: can't
> defragment until after decompression, but can't decompress
> until after defragmentation.
>
> [...] It also becomes necessary to store the state of your
> decompressor across multiple packets, which can get very ugly if header
> fields get split across fragments.
>
> Either one of your recommended solutions would work, but if you want to
> include the total number of fragments I would recommend that each packet
> should also be identified by a sequence number. A simple, but less
> efficient solution, could also be to simply state that any headers which
> extend past the first fragment after compression should not be compressed.
This could be tricky because the size of the compressed IP
header and the MAC addressing and security overhead can
change hop-by-hop. What was in the first fragment on the
first hop may not be in the first fragment on a subsequent
hop, which causes a problem if the forwarding node does
not know how to uncompress the entire packet.
I think that the best solution would be to switch to using
the compressed size and offsets in the fragment headers.
This would allow (un)compression and (de)fragmentation to
be done independently.
> Also, as the author of the 6LoWPAN dissectors for Wireshark, I'm pulling
> my hair out trying to find a way to implement this without throwing away
> all of Wireshark's reassembly support and starting from scratch, or
> implementing some sort of wild speculative guessing.
Would using the compressed size and offsets in the fragment
headers solve this?
-Richard Kelsey
----------------
This message and the information it contains are the proprietary
and confidential property of Ember Corporation and may be privileged.
If you are not the intended recipient, please do not read, copy,
disclose or distribute its contents to any party, and notify the
sender immediately.
_______________________________________________
6lowpan mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/6lowpan
