On 11/20/2008 01:45 AM, Carsten Bormann wrote:
Shoichi just talked to me and made me realize that this can be put in a
simpler way:
Thank you for correcting me at the discussion. My assumption was
different from all of you. I was thinking that only when there was a
strong MIC under the 6lowpan layer, then the UDP checksum could be omitted.
The point was that how the ER or (de)compresser knew whether there
would be strong checksum at the end-to-end. I think the behavior of
the 6lowpan layer should not depend on the upper layer situation.
I think that the decision of the behavior which it sets 0 or 1 should
be an out-of-band parameter.
Where HC-03 says:
C: Checksum:
0: All 16 bits of Checksum are carried in-line. The Checksum MUST
be included if there are no other end-to-end integrity checks
that are stronger than what is provided by the UDP checksum.
Such an integrity check MUST be end-to-end and cover the IPv6
pseudo-header, UDP header, and UDP payload.
So, I propose this bit should be remained. An environment needs to
reserve 2 bytes, and it has a stronger MIC, the administrator tells the
ER to set the C-bit to 1, and then the (de)compresser care the UDP checksum.
Is there any problem of my assumption ?
1: All 16 bits of Checksum are elided. The Checksum is recovered
by recomputing it.
How does the compressor know that there are "other end-to-end integrity
checks
that are stronger than what is provided by the UDP checksum."?
It might on the sending end node.
It's hard to know that on a router, however; just looking at the packet
doesn't tell.
Oracles only help if both cases are supported at both the compressor and
the decompressor side, because the oracle can err.
Gruesse, Carsten
_______________________________________________
6lowpan mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/6lowpan
