The IP header checksum is the 16 bit complement of the 1's complement sum of the header, where the header is treated as a stream of 16 bit "network shorts". That is, divide the header (consisting of an even number of bytes) into consecutive 16 bits network shorts. Add them up, but with using a 1's complement sum (there are excellent reasons for selecting 1's complement, but they don't belong in this node). Flip all bits in the result, and that's your checksum. The same calculation, but on different fields, is also used as a second checksum on some protocols. The most notable of these are TCP and UDP.
In 1's complement, there are 2 representations for zero: 0000000000000000 and 1111111111111111. Note that flipping the bits of the one gives you the other. A header checksum of "0" (allowed for some protocols, e.g. UDP) denotes that the checksum was not calculated. Thus, implementations which do calculate a checksum make sure to give a result of 0xffff rather that 0, when the checksum is actually zero.
Something to note: A header checksum of "0" is not handled correctly on some implementations. In particular, NATting may fail on some devices for packets with uncalculated checksums. For this reason, it's probably wise to avoid. Unfortunately (for them), users don't exactly get much choice in the matter.
The header checksum field is part of the IP header. When calculating what checksum to put on a header, the field is considered to be filled with a "0"; this is exactly equivalent to skipping it, but probably runs faster. When verifying the checksum, you can again take the complement of the 1's complement sum of the header -- including the filled-in value of the header checksum. This comes out 0 if the checksum is correct.
The nature of the header checksum means it cannot detect any re-ordering of the shorts in the header. But that's not a common failure, so there's little point in protecting against it. More common failures -- bit flipping, for instance -- can sometimes be detected by the header checksum. Also, the simple nature of the checksum means it provides no cryptographic defence whatsoever -- use a MAC for that.
In 2002, researchers invented/discovered a novel use of the header checksum for "parasitic computation": you can embed a problem in a header, such that only the correct solution of the problem is the correct checksum. Now fill in all possible values in the checksum, and send these packets out to web servers. A packet with a wrong checksum is dropped; a packet carrying the right answer in its checksum is (or rather, since IP is unreliable, might be) answered. Thus, the remote server(s) perform a computation on your behalf.
It is questionable whether the amount of CPU power "stolen" from the server in this manner is greater than that used by the "thief" to generate and test all packets. Thus, such an attack is (as yet?) imaginary rather than practicable.