Just so we are clear:
- the only place that this compression will now happen is at the
source of the packet on a 6lowpan node
- this does not work for inbound packets
- it doesn't have applicability to legacy tunneled protocols
- for the source to compress the udp checksum the application must have
a layer 7 MIC that calculates the MIC over the application payload
AND the pseudo header and signal to the 6lowpan layer that UDP
checksum compression is ok
- the edge router, when it gets a packet with the c bit set it will
compute the udp checksum and insert it in the full ipv6/udp header
and send the packet on it's way.
- the edge router has no way to verify the ip addresses since there is
no checksum and there is no validity check on the packet header or
the new checksum
- when the MIC is calculated over the IP and udp headers the udp
checksum value should be zero
- in the end we save 2 bytes on some packets
geoff
On Fri, 2008-11-21 at 15:28 -0600, Carsten Bormann wrote:
> >> 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
[email protected]
https://www.ietf.org/mailman/listinfo/6lowpan
