
While this might be acceptable on a single LAN, where the cyclic redundancy check on the data-link frame (e.g., Ethernet or token ring frame) can detect most corruption of the frame, when the datagrams pass through routers, all bets are off. During the 1980s some computer vendors turned off UDP checksums by default, to speed up their implementation of Sun's Network File System (NFS), which uses UDP. It is designed to catch any modification of the UDP header or data anywhere between the sender and receiver.ĭespite UDP checksums being optional, they should always be enabled. It is calculated by the sender, and then verified by the receiver. This UDP checksum is an end-to-end checksum. (This is what happens if an IP header checksum error is detected by IP.) If the sender did compute a checksum and the receiver detects a checksum error, the UDP datagram is silently discarded. If the transmitted checksum is 0, it indicates that the sender did not compute the checksum. If the calculated checksum is 0, it is stored as all one bits (65535), which is equivalent in ones-complement arithmetic. Notice that the length of the UDP datagram appears twice in the checksum computation. In this figure we explicitly show a datagram with an odd length, requiring a pad byte for the checksum computation.

Fields used for computation of UDP checksum. Figure 11.3 shows the pseudo-header along with a UDP datagram. The purpose is to let UDP double-check that the data has arrived at the correct destination (i.e., that IP has not accepted a datagram that is not addressed to this host, and that IP has not given UDP a datagram that is for another upper layer). This pseudo-header includes certain fields from the IP header. Next, both UDP and TCP include a 12-byte pseudo-header with the UDP datagram (or TCP segment) just for the checksum computation. (That is, this possible pad byte is not transmitted.)


The solution is to append a pad byte of 0 to the end, if necessary, just for the checksum computation. First, the length of the UDP datagram can be an odd number of bytes, while the checksum algorithm adds 16-bit words. With UDP the checksum is optional, while with TCP it is mandatory.Īlthough the basics for calculating the UDP checksum are similar to what we described in Section 3.2 for the IP header checksum (the ones complement sum of 16-bit words), there are differences. Both UDP and TCP have checksums in their headers to cover their header and their data. Recall that the checksum in the IP header only covers the IP header ”it does not cover any data in the IP datagram. The UDP checksum covers the UDP header and the UDP data.
