> We could explicitly state, for clarity, that you MUST NOT compress > anything outside the first fragment,
That is a nice editorial clarification. I'm in favor of adding that. > 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. I'd say: Since you can't do that, don't do that. Also, I'd say we shouldn't try to use HC for RPL headers. Instead, we should design RPL headers to be sane in the first place. I have no idea where the notion came from that RPL must do something dumb and then HC needs to mop up after it. (I also don't understand why these headers must be so large that they require every packet to be L2-fragmented. It's not like RPL is a general Internet protocol; it's meant for LLNs, which all react adversely to giant overheads.) > If that is not a problem, then maybe we can just state that thou MUST > NOT compress outside fragment 1. This is what I thought we were converging on? Gruesse, Carsten _______________________________________________ 6lowpan mailing list [email protected] https://www.ietf.org/mailman/listinfo/6lowpan
