Standards/Ethernet/UDP

UDP payload

With UDP, computer applications can send messages, in this case referred to as datagrams, to other hosts on an Internet Protocol (IP) network without requiring prior communications to set up special transmission channels or data paths. The protocol was designed by David P. Reed in 1980 and formally defined in RFC 768.

UDP uses a simple transmission model without implicit handshaking dialogues for providing reliability, ordering, or data integrity. Thus, UDP provides an unreliable service and datagrams may arrive out of order, appear duplicated, or go missing without notice. UDP assumes that error checking and correction is either not necessary or performed in the application, avoiding the overhead of such processing at the network interface level.

UDP provides application multiplexing via port numbers and integrity verification via checksum of the header and payload.

The following table shows the content of an UDP datagram

byte\bit offset	0 – 15																16 – 31
0	Source Port Number																Destination Port Number
4	Length																Checksum
8	Data

The UDP header consists of 4 fields, each of which is 2 bytes.

Source port number

This field identifies the sender's port when meaningful and should be assumed to be the port to reply to if needed. If not used, then it should be zero. If the source host is the client, the port number is likely to be an ephemeral port number. If the source host is the server, the port number is likely to be a well-known port number.

Destination port number

This field identifies the receiver's port and is required. Similar to source port number, if the client is the destination host then the port number will likely be an ephemeral port number and if the destination host is the server then the port number will likely be a well-known port number.

Length

A field that specifies the length, in bytes, of the entire datagram: header and data. The minimum length is 8 bytes since that is the length of the header. The field size sets a theoretical limit of 65,535 bytes (8 byte header + 65,527 bytes of data) for an UDP datagram. The practical limit for the data length which is imposed by the underlying IPv4 protocol is 65,507 bytes (65,535 − 8 byte UDP header − 20 byte IP header).

Checksum

The checksum field is used for error-checking of the header and data. The checksum computation also takes in account a part of the IP header. If no checksum is generated by the transmitter, the field uses the value all-zeros. This field is not optional for IPv6.

The calculation method is the same as for the IP checksum (sum and bitwise inversion). If the checksum calculation results in the value zero (all 16 bits 0) it should be sent as its one's complement (all 1's).

For IPv4, the checksum calculation is done on the following data (pseudo-header, UDP header and data):

bits	0 – 7								8 – 15								16 – 23								24 – 31
0	Source IP address
32	Destination IP address
64	Zeros								Protocol (11h)								UDP length
96	Source UDP Port																Destination UDP Port
128	UDP length																Checksum (0000h)
160	UDP data

Example

Sending hello world!<cr><lf> in an UDP frame from IP address / port 01234567 / 0017_h to IP address / port 89ABCDEF / 1717_h would give the following checksum calculation:

info	data	part. sum	total sum	checksum
Source IP address	0123	9E4C	348A	CB75
	4567
Destination IP address	89AB
	CDEF
IP protocol (UDP)	0011
UDP length	0016
Source UDP port	0017	1744
DestinationUDP port	1717
UDP length	0016
checksum	0000
He	4865	7EF9
ll	6C6C
o	6F20
wo	776F
rl	726C
d!	6421
<cr><lf>	0D0A

With this, the Ethernet frame will be:

Ethernet header	E0E1E2E3E4E5 F0F1F2F3F4F5 0800
IP header	4500 002A 0000 4000 1011 CC9E 0123 4567 89AB CDEF
UDP header	0017 1717 0016 CB75
Payload	48 65 6C 6C 6F 20 77 6F 72 6C 64 21 0D 0A
Padding	00 00 00 00
Eth. CRC	52 5D A4 CF