Hi, William Herrin: > Hi folks, > > I've recently done a deep dive in to IP checksums and I've run in to > something I don't understand. Any insight would be helpful. > > rte_ipv4_cksum() is implemented as: > > return (cksum == 0xffff) ? cksum : (uint16_t)~cksum; > > Which means: if the sum is zero, return -0 (0xffff) never +0 (0x0000). > Welcome to the wonderful world of 1's complement arithmetic. > > RFC 1624, on the other hand, says: > > "In one's complement, there are two representations of zero: the all zero > and the all one bit values, often referred to as +0 and -0. One's > complement addition of non-zero inputs can produce -0 as a result, but > never +0. Since there is guaranteed to be at least one non-zero field in > the IP header, and the checksum field in the protocol header is the > complement of the sum, the checksum field can never contain ~(+0), which is > -0 (0xFFFF). It can, however, contain ~(-0), which is +0 (0x0000)." > > Which I understand to mean that +0 (0x0000) is a legal value in an IPv4 > checksum field, but -0 (0xffff) is not. > > Is this a bug? Is there a more authoritative source for which zero is > correct in an IPv4 header? Please help me find the error in my > understanding. > > Thanks, > Bill Herrin > >
Related threads: https://mails.dpdk.org/archives/users/2019-March/004021.html https://mails.dpdk.org/archives/dev/2019-April/128473.html Cheers!
