Subject: Re: [6lowpan] closing on update to HC draft

From: "Reddy, Joseph" <[email-masked]>
Date: Thu, 4 Mar 2010 14:09:12 -0600

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