That's right. The checksum is always 'virtually there' when it's elided. As opposde to NULL.
We need to add text that when tunneling another protocol that protects itself, the checksum can be elided but has to be restored when the packet is expanded. This is the same spirit but a slightly different case because in the tunnel case, the source and destination that are protected by the MIC (of the inner packet) are different from the outer header protected by UDP, though the UDP protection does not help so much that it would be required to leave it uncompressed. Would you propose text? We have a few typos to fix so we can always publish a cleaner 04 before we address the other comments from the WG meeting like contexts, link local, etc... Pascal >-----Original Message----- >From: Carsten Bormann [mailto:[EMAIL PROTECTED] >Sent: mercredi 19 novembre 2008 17:48 >To: Pascal Thubert (pthubert) >Cc: Carsten Bormann; Erik Nordmark; Shoichi Sakane; 6lowpan; Geoff Mulligan >Subject: Re: [6lowpan] UDP checksum elide > >> The only node that can >> compress the checksum is the transport endpoint that sources the >> compressed packet. > >That might be good material for a note in HC-03 then. > >> Also, there are tons of legacy field buses protocols in that space >> that >> we will be tunneling over UDP/6LoWPAN. In that case also, the checksum >> will be elided. > >More text for the note. The tunneling protocol would have to include >a checksum covering the pseudo-header, though. > >Gruesse, Carsten _______________________________________________ 6lowpan mailing list [email protected] https://www.ietf.org/mailman/listinfo/6lowpan
