UDP Message Format

(Page 1 of 2)

What's the magic word when it comes to UDP? Right, simple. This is true of the
operation of the protocol, and it is also true of the format used for UDP messages.
Interestingly, however, it is here that we will actually encounter probably the only
aspect of UDP that is not simple. I bet that got you interested, huh? Okay, well, it
was a worth a try. 

In keeping with the goal of efficiency, the UDP header is only eight bytes in length;
this contrasts with the TCP header size of 20 bytes or more. Table 147 and Figure
200 show the format of UDP messages.

Table 147: UDP Message Format

Size
Field Name Description
(bytes)
Source Port: The 16-bit port number of the process that
originated the UDP message on the source device. This will
normally be an ephemeral (client) port number for a request
Source Port 2
sent by a client to a server, or a well-known/registered
(server) port number for a reply sent by a server to a client.
See the section describing port numbers for details.
Destination Port: The 16-bit port number of the process
that is the ultimate intended recipient of the message on the
Destination destination device. This will usually be a well-
2
Port known/registered (server) port number for a client request,
or an ephemeral (client) port number for a server reply.
Again, see the section describing port numbers for details.
Length: The length of the entire UDP datagram, including
Length 2
both header and Data fields.
Checksum: An optional 16-bit checksum computed over
Checksum 2 the entire UDP datagram plus a special “pseudo header” of
fields. See below for more information.
Data Variable Data: The encapsulated higher-layer message to be sent.

 
Figure 200: UDP Message Format
Figure 200: UDP Message Format

UDP Message Format

(Page 2 of 2)

The Checksum Field and the UDP Pseudo Header

The UDP Checksum field is the one area where the protocol actually is a bit
confusing. The concept of a checksum itself is nothing new; they are used widely in
networking protocols to provide protection against errors. What's a bit odd is this
notion of computing the checksum over the regular datagram and also a pseudo
header. What this means is that instead of calculating the checksum over just the
fields in the UDP datagram itself, the UDP software first constructs a “fake”
additional header that contains the following fields (Figure 201):

o The IP Source Address field.

o The IP Destination Address field.

o The IP Protocol field.

o The UDP Length field.

 
 Figure 201: UDP Pseudo Header Format

The total length of this “pseudo header” is 11 bytes. It is padded to 12 bytes with a
byte of zeroes and then prepended to the real UDP message. The checksum is then
computed over the combination of the pseudo header and the real UDP message,
and the value is placed into the Checksum field. The pseudo header is used only for
this calculation and is then discarded; it is not actually transmitted. The UDP
software in the destination device creates the same pseudo header when calculating
its checksum to compare to the one transmitted in the UDP header.

Computing the checksum over the regular UDP fields protects against bit errors in
the UDP message itself. Adding the pseudo header allows the checksum to also
protect against other types of problems as well, most notably the accidental delivery
of a message to the wrong destination. The checksum calculation in UDP, including
the use of the pseudo header is exactly the same as the method used in TCP
(except the Length field is different in TCP). See the topic describing TCP checksum
calculation for a full description of why the pseudo header is important, and some of
the interesting implications of using IP fields in transport layer datagram calculations.

Key Concept: UDP packages application layer data into a very simple
message format that includes only four header fields. One of these is an
optional checksum field; when used, the checksum is computed over both the
real header and a “pseudo header” of fields from the UDP and IP headers, in a
manner very similar to how the TCP checksum is calculated.

Note that the use of the Checksum field is optional in UDP. If it is not used, it is set to
a value of all zeroes. This could potentially create confusion, however, since when
the checksum is used, the calculation can sometimes result in a value of zero. To
avoid having the destination think the checksum was not used in this case, this zero
value is instead represented as a value of all ones (65,535 decimal).
Description:

Protocol suite: TCP/IP.

Protocol type: Connectionless transport layer protocol.
IP Protocol: 17.
Ports:
Related protocols: UDP-Lite, Lightweight User Datagram Protocol.
SNMP MIBs: iso.org.dod.internet.mgmt.mib-2.udp (1.3.6.1.2.1.7).
iso.org.dod.internet.mgmt.mib-2.udpMIB (1.3.6.1.2.1.50).
iso.org.dod.internet.experimental.ipv6UdpMIB (1.3.6.1.3.87).
Working groups:
Links:

RFC 1122, section 4.1:

The User Datagram Protocol offers only a minimal transport service -- non-guaranteed
datagram delivery -- and gives applications direct access to the datagram service of the IP
layer. UDP is used by applications that do not require the level of service of TCP or that wish
to use communications services (e.g., multicast or broadcast delivery) not available from
TCP.

UDP is almost a null protocol; the only services it provides over IP are checksumming of data
and multiplexing by port number. Therefore, an application program running over UDP must
deal directly with end-to-end communication problems that a connection-oriented protocol
would have handled -- e.g., retransmission for reliable delivery, packetization and
reassembly, flow control, congestion avoidance, etc., when these are required. The fairly
complex coupling between IP and TCP will be mirrored in the coupling between UDP and
many applications using UDP.

MAC header IP header UDP header Data :::

UDP header:

1
00 01 02 03 04 05 06 07 08 09 10 11 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31
2
Source Port Destination Port
Length Checksum
Data :::

Source Port. 16 bits.

The port number of the sender. Cleared to zero if not used.

Destination Port. 16 bits.

The port this packet is addressed to.
Length. 16 bits.
The length in bytes of the UDP header and the encapsulated data. The minimum value for
this field is 8.

Checksum. 16 bits.
Computed as 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 as needed with zero
bytes at the end to make a multiple of two bytes. If the checksum is cleared to zero, then
checksuming is disabled. If the computed checksum is zero, then this field must be set to
0xFFFF.

When transported by IPv4, the pseudo header contains the following fields:

1
00 01 02 03 04 05 06 07 08 09 10 11 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31
2
Source IPv4 address
Destination IPv4 address
0 Protocol Total length

The checksum is not optional when transported by IPv6. In this case, the pseudo header
contains the following fields:

1
00 01 02 03 04 05 06 07 08 09 10 11 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31
2
Source IPv6 address :::
Destination IPv6 address :::
Upper layer packet length
0 Next header

Data. Variable length.