In message <2721.1015929368@brandenburg.cs.mu.OZ.AU>Robert Elz writes
[...]

>It's a little more complex than that because of the 1's complement
>(pretty easy when just doing an increment of the TTL by one, but the
>same technique should be used for all header adjustments).


The placement of the TTL field, and carries, make it a little tricky.
IIRC, it took two attempts to get an RFC with a correct description.


>  | This saves you both validating and recalculating the full header
>  | checksum.
>
>You're supposed to validate the header checksum anyway (but that many
>don't bother is part of the reason it no longer exists in IPv6).   Avoiding
>recalculating isn't just to save your system cpu cycles, it also helps
>protect against inadvertent changes that might have been made in your
>node (bad ram, code bugs, ...), or elsewhere (if you didn't validate).

Robert, that does't agree with my recollection or reasearch.  I
recall Steve (IIRC) commenting that the major reason was that IPv6
mandated a link-level check; and at that time, it was widely believed
that strong link-level checks made an IP-level check redundant.
(The practice of incremental update *without* validation suggested it
wouldn't hurt too much).

Current data shows there really *are* NIC errors, which do cause
packets with valid MAC CRCs but incorrect IP headers, even on a single
LAN hop.  Whether it's worth detecting these errors before they get to
the (possily incorrect) endhost is an individual choice.

I guess by "recalculate" you mean a *non*-incremental recalculation?
If so, I agree.