On Wed, 2008-11-19 at 07:00 -0600, Carsten Bormann wrote:
> The important thing here: we have to consider both the 6lowpan nodes
> (which may want to save two bytes and some unneeded UDP checksum
> computation) and the correspondent nodes (which have to work with
> legacy OSes and firewalls, but now can't accommodate non-ULTP-friendly
> NATs).
Does the MIC cover the UDP Pseudoheader checksum? If so there is no
savings of computation since the checksum needs to be calculated anyway
or is the checksum not covered by the MIC?
> A 6lowpan node that sends out an IP/UDP/ULTP packet compresses away
> the UDP checksum and leaves only the ULTP MIC. The decompressor at
> the 6lowpan boundary builds a UDP header that includes computed length
> and a newly generated checksum *after it has checked the ULTP MIC*.
> The correspondent node runs a legacy OS that does not know anything
> about ULTP, so the app writer is quite happy that the app can simply
> set up a UDP socket and do the ULTP processing (which may or may not
> include checking the MIC -- irrelevant here) in the app; the OS does
> the UDP checksum checking.
Are you saying that the 6lowpan edge router strips off the ULTP
(whatever that is) before sending the packet on? If it doesn't strip
the ULTP then the legacy OS at the other end needs to know/understand
this ULTP, right?
>
> One the way from the correspondent node to the 6lowpan node, an app
> that implements the ULTP computes the MIC to allow the compressor at
> the 6lowpan boundary to check it and, if that *and* the UDP checksum
> were correct, to compress away the UDP checksum.
So is the checksum calculated and included in the bytes that are covered
by the MIC?
geoff
_______________________________________________
6lowpan mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/6lowpan
