Hi Geoff,
The current HC/fragmentation also works over multiple fragments, as long as,
each compressed fragement is wholly contained in a single fragment. That is,
you cannot have any compressed header span more than fragment.
The other issue is forward comptability. Will devices implementing this draft
be able to forward packets that have a new compression scheme ( say, a
compressed TCP header ) ? I thought this was an issue and the suggestions were
to either - include a "last fragment" indication or make offsets point to
compressed data.
-Regards, Joseph
------------------------------
Carsten,
You did indicate in a message that you thought that 4944 was fine as it was
as it does NOT say that you can compress anything that is not in the first
fragment.
My listening to the discussion seemed to be that folks didn't think that this
was sufficient. I also don't think that it is sufficient.
We could explicitly state, for clarity, that you MUST NOT compress anything
outside the first fragment, but then what happens if someone decides to use RPL
or some other source routed protocol that inserts a routing extension header or
some other extension header that "pushes" a compressed header into the second
fragment. Would the node have to uncompress that header?
If that is not a problem, then maybe we can just state that thou MUST NOT
compress outside fragment 1.
If it is a problem, then this seems like a good fix.
geoff
_______________________________________________
6lowpan mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/6lowpan
