I would be happy to close on the HC-06 with a note saying that
compression doesn't extend past the first fragment.
The main issue that I can see causing fragments to be pushed into
subsequent fragments is not with the ROLL packets but with any packets
that are source routed and use the IPv6 routing extension header (sect
4.4 of rfc2460).
For example, if ROLL is used with the DAG information held only on the
edge router and routers within the wireless network rely on source
routing inserted at the edge router, the routing extension headers would
be before the UDP header and may push the UDP header into the next
fragment.
However, this problem could be addressed with a later RFC which
addresses both fragmentation and addresses compression of the routing
extension header. We don't need to hold up the progress of the HC-06
draft to resolve this issue.
Off topic, I do think that the HC-06 header compression would be good to
use with the ROLL addresses. This would allow the same software and
context information to be re-used, rather than inventing a new IPv6
address compression scheme for ROLL.
Daniel.
Carsten Bormann wrote:
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
--
__________________________________________________
Daniel Gavelle, Software Engineer
Tel: +44 114 281 2655
Fax: +44 114 281 2951
Jennic Ltd, Furnival Street, Sheffield, S1 4QT, UK
Comp Reg No: 3191371 Registered In England
http://www.jennic.com
__________________________________________________
_______________________________________________
6lowpan mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/6lowpan
