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?
No, the legacy OS hands the UDP payload to the app, which parses out
the ULTP header from that and handles the data.
I'm not convinced that all of this complexity is worth the minor
optimization for this edge case.
I think the solution we have now arrived at is quite clean and not
very complex; the danger of sending data to the wrong recipient is
present but limited (and that danger is present but only somewhat more
limited with a UDP checksum in place).
The cost of the solution is that the decompressors will have to
compute checksums; this is not a problem for an end system
decompressor (which in most cases will not compute it, but rather know
the checksum it would compute is correct) or for a intra-lowpan
forwarder (that can simply leave things compressed), so the cost only
occurs at an edge router, where it is quite bearable.
The win is saving two bytes per packet from a sensor that applies
application-level^W upper-transport-layer-level security. Limited,
but depending on the size of this packet we are talking about maybe 5
% of the total bytes, which may be worth some code. Less data will
also relieve interference just a bit, which may be of interest in
particular for 868 MHz (packets get almost a millisecond shorter
there). The biggest win is in the heads of design engineers who can't
stand sending two redundant bytes, though :-)
Gruesse, Carsten
_______________________________________________
6lowpan mailing list
6lowpan@ietf.org
https://www.ietf.org/mailman/listinfo/6lowpan
