User Datagram Protocol

2017-11-03 09:05:03

There are two protocols at the Transport Layer that Application Layer protocols typically use for transporting data: Transmission Control Protocol (TCP) and User Datagram Protocol (UDP). UDP is the Transport Layer protocol that offers a minimum of services, but also has the minimum overhead for Application Layer protocols that do not require an end-to-end reliable delivery service.

Introduction to UDP

UDP is a minimal Transport Layer protocol that is a direct reflection of the datagram services of IP, except that UDP provides a method to pass the message portion of the UDP message to the Application Layer protocol. UDP has the following characteristics:

ConnectionlessUDP messages are sent without a UDP-based connectionestablishment negotiation.

UnreliableUDP messages are sent as datagrams without sequencing oracknowledgment. The Application Layer protocol must recover lost messages. Typical UDP-based Application Layer protocols either provide their own reliable service or retransmit UDP messages periodically or after a defined time-out value.

Provides identification of Application Layer protocolsUDP provides a mechanism to send messages to a specific Application Layer protocol or process on an internetwork host. The UDP header provides both source and destination process identification.

Provides checksum of UDP messageThe UDP header provides a 16-bit checksum over the entire UDP message.

UDP does not provide the following services for end-to-end delivery:

BufferingUDP does not provide any buffering of incoming or outgoing data. The Application Layer protocol must provide all buffering.

SegmentationUDP does not provide any segmentation of large blocks of data. Therefore, the application must send data in small enough blocks sothat the IP datagrams for the UDP messages are no larger than the Maximum Transmission Unit (MTU) of the interface on which they are sent; otherwise IP on the sending host fragments the UDP message.

Flow controlUDP does not provide any sender-side or receiver-side flow control. UDP message senders can react to the receipt of an Internet Control Message Protocol (ICMP) Source Quench message, but it is not required.

Uses for UDP

Because UDP does not provide any services beyond Application Layer protocol identification and a checksum, it is hard to imagine why UDP is needed at all. However, the following are specific uses for sending data using UDP:

Lightweight protocolTo conserve memory and processor resources, some Application Layer protocols require the use of a lightweight protocol that performs a specific function using a simple exchange of messages. A good example of a lightweight protocol is Domain Name System (DNS) name queries. Typically, a DNS client sends a DNS Name Query message to a DNS server. The DNS server responds with a DNS Name Query Response message. If the DNS server does not respond, the DNS client retransmits the DNS Name Query.

Imagine the resources required at the DNS server if all the DNS clients used TCP rather than UDP. All DNS interactions would be sent reliably, but the DNS server would have to support hundreds or, on the Internet, thousands of TCP connections. The low-overhead solution of using UDP is the best choice for simplerequest-reply-based Application Layer protocols.

Reliability provided by the Application Layer protocolIf the Application Layer protocol provides its own reliable data transfer service, there is no need for the reliable services of TCP. Examples of reliable Application Layer protocols are Trivial File Transfer Protocol (TFTP) and Network File System (NFS).

Reliability not required due to periodic advertisement processIf theApplication Layer protocol periodically advertises information, reliable delivery is not required. If an advertisement is lost, it is announced again at the period interval. An example of an Application Layer protocol that uses periodic advertisements is the Routing Information Protocol (RIP).

One-to-many deliveryUDP is used as the Transport Layer protocol whenever Application Layer data must be sent to multiple destinations using an IP multicast or broadcast address. TCP can be used only for one-to-one delivery. For example, a broadcast NetBIOS Name Query is sent using UDP.

The UDP Message

UDP messages are sent as IP datagrams. A UDP message consisting of a UDP header and a message is encapsulated with an IP header using IP Protocol number 17 (0x11). The message can be a maximum size of 65,507 bytes: 65,535 minus the minimum-size IP header (20 bytes) and the UDP header (8 bytes). The resulting IP datagram is thenencapsulated with the appropriate Network Interface Layer header and trailer. Figure 11-1 shows the resulting frame. UDP is described in RFC 768.

Figure 11-1: UDP message encapsulation showing the IP header and Network Interface Layer header and trailer.

In the IP header of UDP messages, the Source IP Address field is set to the host interface that sent the UDP message. The Destination IP Address field is set to the unicast address of a specific host, an IP broadcast address, or an IP multicast address.

The UDP Header

The UDP header is a fixed-length size of 8 bytes consisting of four fixed-length fields, as Figure 11-2 shows.

Figure 11-2: The structure of the UDP header.

The fields in the UDP header are defined as follows:

Source PortA 2-byte field used to identify the source Application Layer protocol sending the UDP message. The use of a source port is optional and, when not used, is set to 0. IP multicast traffic, such as videocasts sent using UDP, can use 0 because no reply to the video traffic is assumed. Typical Application Layer protocols use the source port of the incoming UDP message as the destination port for replies.

Destination PortA 2-byte field used to identify the destination Application Layer protocol. The combination of the IP header's destination IP address and the UDP header's destination port provides a unique, globally significantaddress for the process to which the message is sent.

LengthA 2-byte field used to indicate the length in bytes of the UDP message (UDP header and message). The minimum length is 8 bytes (the UDP header's size), and the maximum is 65,515 bytes (maximum-sized IP datagram of 65,535 bytes minus the minimum-sized IP header of 20 bytes). The actual maximum length is confined by the MTU of the link on which the UDP message is sent. The Length field is a redundant field. The UDP length can always be calculated from the Total Length and the IP Header Length fields in the IP header (UDP length = payload length = total length – 4IP header length [in 32-bit words]).

ChecksumA 2-byte field that provides a bit-level integrity check for the UDP message (UDP header and message). The UDP checksum calculation uses the same method as the IP header checksum over the UDP pseudo header, the UDP header, the message, and, if needed, a padding byte of 0x00. The padding byte is used only if the message's length is an odd number of bytes. The use of the UDP Checksum field is optional. If not used, the UDP Checksum field is set to 0. For details on the checksum calculation, see Chapter 5, "Internet Protocol Basics."

Note
TCP/IP for the Microsoft Windows Server 2003 family and Windows XP always calculates a value for the UDP checksum.

The following Network Monitor trace (Capture 11-01 in the Captures folder on the companion CD-ROM) shows the structure of the UDP header for a DNS Name Query:

+ ETHERNET: ETYPE = 0x0800 : Protocol = IP: DOD Internet Protocol + IP: ID = 0x4001; Proto = UDP; Len: 58 UDP: Src Port: DNS, (53); Dst Port: DNS (53); Length = 38 (0x26) UDP: Source Port = DNS UDP: Destination Port = DNS UDP: Total length = 38 (0x26) bytes UDP: UDP Checksum = 0x6AA1 UDP: Data: Number of data bytes remaining = 30 (0x001E) + DNS: 0x2:Std Qry for www.acme.com. of type Host Addr on class INET addr.

Note

The last item in the Network Monitor display of the UDP header (UDP: Data: Number of data bytes remaining) is a Network Monitor information field and does not correspond to a field in the UDP header.

The UDP Pseudo Header

The UDP pseudo header is used to associate the UDP message with the IP header. The UDP pseudo header is added to the beginning of the UDP message only for the checksum calculation, and is not sent as part of the UDP message. The UDP pseudo header assures that a routing or fragmentation process did not improperly modify the IP header's key fields.

The UDP pseudo header consists of the Source IP Address field, the Destination IPAddress field, the Protocol field for UDP (17 or 0x11), an Unused field set to 0, and the UDP Length field. When sending a UDP message, UDP is aware of all of these values. When receiving a UDP message, IP indicates all of these values to UDP. Figure 11-3 shows the UDP pseudo header.

Figure 11-3: The structure of the UDP pseudo header.

The UDP Checksum field is calculated over the combination of the UDP pseudo header, the UDP message, and a 0x00 padding byte if needed. The checksum calculation relies on summing 16-bit words. Therefore, the checksum quantity must be an even number of bytes. The padding byte is used only if the length of the message is an odd number of bytes. The padding byte is not included in the UDP length and is not sent as part of the UDP message. Figure 11-4 shows the resulting quantity for the calculation of the UDP Checksum field.

Figure 11-4: The resulting quantity used for the UDP Checksum calculation.

Note

The UDP pseudo header and Checksum field are not providing data authentication and integrity as the IP Security (IPsec) Authentication header does. IP header fields can be modified as long as the UDP Checksum field is updated. This is how a Network Address Translator (NAT) works. An NAT is a router that translates public and private addresses during the forwarding process. For example, when translating a source IP address from a private address to a public address, the NAT also recalculates the UDP checksum.

UDP Ports

A UDP port defines a location or message queue for the delivery of messages for Application Layer protocols using UDP services. Included in each UDP message is the source port (the message queue from which the message was sent) and a destination port (the message queue to which the message was sent). The Internet Assigned Numbers Authority (IANA) assigns port numbers, known as well-known port numbers, to specific Application Layer protocols. Table 11-1 shows well-known UDP port numbers used by the Windows Server 2003 family and Windows XP components.

Table 11-1: Well-Known UDP Port Numbers
Port Number	Application Layer Protocol
53	DNS
67	BOOTP client (Dynamic Host Configuration Protocol [DHCP])
68	BOOTP server (DHCP)
69	TFTP
137	NetBIOS Name Service
138	NetBIOS Datagram Service
161	Simple Network Management Protocol (SNMP)
445	Direct hosting of Server Message Block (SMB) datagrams over TCP/IP
520	RIP
1812, 1813	Remote Authentication Dial-In User Service (RADIUS)

See http://www.iana.org/assignments/port-numbers for the most current list of IANA-assigned UDP port numbers.

Typically, the server side of an Application Layer protocol listens on the well-knownport number. The client side of Application Layer protocols uses either the well-known port number or, more commonly, a dynamically allocated port number. These dynamically allocated port numbers are used for the duration of the process and are also knownas ephemeral or short-lived ports. The following registry setting determines the rangeof TCP and UDP port numbers for TCP/IP for the Windows Server 2003 family andWindows XP:

MaxUserPort

Location: HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesTcpipParameters Data type: REG_DWORD Valid range: 5000–65534 Default: 5000 Present by default: No

By default, the maximum port number is 5000. Dynamically allocated port numbers are within the range of 1024 through 5000 (0 through 1023 are reserved for well-known ports controlled by the IANA).

A UDP port number can be referenced by name by a Microsoft Windows Sockets application using the GetServByName() function. The name is resolved to a UDP port number through the Services file stored in the %SystemRoot%System32DriversEtc folder.

A sending node determines the destination port (using either a specified value or the GetServByName() function) and the source port (either specified or by obtaining adynamically allocated port through Windows Sockets). The sending node then indicates the source IP address, destination IP address, source port, destination port, and the message to be sent to TCP/IP. The UDP module calculates the length and the checksum, and indicates the UDP message with the appropriate source IP address and destination IP address to the IP module.

When receiving a UDP message at the destination, IP verifies the IP header and, based on the value of 17 (0x11) in the Protocol field, passes the UDP message, the source IP address, and the destination IP address to the UDP module. After verifying the UDP checksum, the UDP module verifies the destination port. If a process is listening on the port, the UDP message is passed to the application. If no process is listening on the port, UDP informs the ICMP module, an ICMP Destination Unreachable-Port Unreachable message is sent to the sender, and the UDP message is discarded.

Figure 11-5 shows the process of demultiplexing an incoming UDP message.

Figure 11-5: The demultiplexing of a UDP message to the appropriate Application Layer protocol using the IP Protocol field and the UDP Destination Port field.

Best Practice

UDP ports are separate from TCP ports, even for the same port number. A UDP port represents a UDP message queue for an Application Layer protocol. A TCP port represents one side of a TCP connection for an Application Layer protocol. The Application Layer protocol using the UDP port is not necessarily the same Application Layer protocol using the TCP port. A good example of the differentiation between TCP and UDP Application Layer protocols is the Extended Filename Server (EFS) protocol, which uses TCP port 520, and RIP, which uses UDP port 520. Clearly these are separate Application Layer protocols. Therefore, it is good practice to never refer to a port by just its port number because the port number alone is ambiguous. Always refer to either a TCP port number or a UDP port number.

Summary

UDP provides a connectionless and unreliable delivery service for applications that do not require the guaranteed delivery service of TCP. Application Layer protocols use UDP for lightweight interaction, for broadcast or multicast traffic, or when the Application Layer protocol provides its own reliable delivery service. The UDP header provides a checksum and the identification of source and destination port numbers to multiplex UDP message data to the proper Application Layer protocol.