> Another recommendation might be to reconsider default coverage length.
> RFC3228 recommends that the default is to checksum over the entire
> packet, but then this basically becomes UDP so why not just use UDP?
Because Lite was designed as an in-situ replacement of UDP, the IESG gotcold feet, and punted it to a different protocol number. It's the safe default.
(Once it was at a different protocol number, it didn't have to look likeUDP at all. But by that time the document was written and approved. Theseare the wonders of the standards process.)
> For the case of tunneling at least, maybe the recommendation should be
> that the UDP-Lite checksum only covers the pseudo header and UDP
> header, i.e. the minimum coverage to compensate for lack of IP header
> checksum in IPv6.
It doesn't cover for the lack of IP header checksum,
unless you're suggesting it be checked at each hop.
Covering the minimum of UDP-Lite/IP pseudoheader does
nothing for what is carried - a tunneller can argue that,
from his perspective, he gains nothing over zero-checksum
UDP and doesn't care about polluting other ports, so
why not simply use UDP and turn off UDP checksums?
Where Lite has an advantage is that it can and should
also cover encap headers not otherwise covered end to end
(e.g. MPLS stack in MPLS-in-UDP, or a GRE shim without
a GRE checksum, or RTP headers) but that is case-specific
and requires engineering judgement to select. And that
also offers a subtle benefit to the tunneller.
Again, full checksum coverage is the safe default for
people who don't think about this.
> Besides that, we are
> pushing vendors to get rid of protocol specific offloads
But not for offloading TCP or UDP, eh?
> For instance, when receiving a packet
> we prefer that a device just gives us the checksum as calculated over
> the whole packet, it is then easy for the stack to apply that value to
> verify any UDP, TCP, GRE checksums etc. in the packet (please look at
Tom Herbert, "UDP Encapsulation in Linux" netdev 0.1,
Ottawa Canada, Feb 2015.
Your paper doesn't mention Lite - sigh. But hey,
different protocol number...
This assumes that other inner one's complement checksums
are good if the outer one is good - imo a bit risky,
because one's complement is so weak.
And of even less use for assuming stronger tunnelled CRCs
are good. (an outer Eth CRC has a different link scope to
the full path of tunnelled devices, so is not that good an
indicator the content is safe.)
lloyd.wood <at> yahoo.co.uk