RFC 768 J. Postel ISI 28 August 1980
This protocol provides a procedure for application programs to send messages to other programs with a minimum of protocol mechanism. The protocol is transaction oriented, and delivery and duplicate protection are not guaranteed. Applications requiring ordered reliable delivery of streams of data should use the Transmission Control Protocol (TCP) [2].
0 7 8 15 16 23 24 31 +--------+--------+--------+--------+ | Source | Destination | | Port | Port | +--------+--------+--------+--------+ | | | | Length | Checksum | +--------+--------+--------+--------+ | | data octets ... +---------------- ... User Datagram Header Format
Destination Port has a meaning within the context of a particular internet destination address.
Length is the length in octets of this user datagram including this header and the data. (This means the minimum value of the length is eight.)
Checksum is the 16-bit one's complement of the one's complement sum of a pseudo header of information from the IP header, the UDP header, and the data, padded with zero octets at the end (if necessary) to make a multiple of two octets.
The pseudo header conceptually prefixed to the UDP header contains the source address, the destination address, the protocol, and the UDP length. This information gives protection against misrouted datagrams. This checksum procedure is the same as is used in TCP.
0 7 8 15 16 23 24 31 +--------+--------+--------+--------+ | source address | +--------+--------+--------+--------+ | destination address | +--------+--------+--------+--------+ | zero |protocol| UDP length | +--------+--------+--------+--------+If the computed checksum is zero, it is transmitted as all ones (the equivalent in one's complement arithmetic). An all zero transmitted checksum value means that the transmitter generated no checksum (for debugging or for higher level protocols that don't care).
[1] | Postel, J., "Internet Protocol," RFC 760, USC/Information Sciences Institute, January 1980. |
[2] | Postel, J., "Transmission Control Protocol," RFC 761, USC/Information Sciences Institute, January 1980. |
[3] | Postel, J., "Internet Name Server," USC/Information Sciences Institute, IEN 116, August 1979. |
[4] | Sollins, K., "The TFTP Protocol," Massachusetts Institute of Technology, IEN 133, January 1980. |
[5] | Postel, J., "Assigned Numbers," USC/Information Sciences Institute, RFC 762, January 1980. |