Classroom Public page

Week 5: UDP -- Datagram Services

1,121 words

UDP is the minimal transport protocol: a source port, a destination port, a length, a checksum, and then the payload. No connection, no acknowledgment, no retransmission. This week you see why DNS and DHCP choose UDP and what that choice costs.


Theme

TCP guarantees delivery, ordering, and error correction. UDP guarantees nothing except that the receiver knows where the packet came from and which port it is aimed at. That sounds like a bad deal -- but for DNS, it is the right deal. A DNS query is a single question and a single answer. You do not want to establish a TCP connection, exchange bytes, and tear it down just to ask "what is the IP for example.com?" UDP lets you ask and receive an answer in two packets. DHCP works the same way. This week you trace both protocols through their full exchanges in packet captures.

Reading (~45 minutes)

  1. Stevens TCP/IP Illustrated Ch 11 ("UDP: User Datagram Protocol"): the UDP header; why UDP exists; what applications use it
  2. Stevens TCP/IP Illustrated Ch 14 ("DNS: The Domain Name System") -- §14.1-14.3 only: DNS on UDP; query format; response format
  3. Stevens TCP/IP Illustrated Ch 16 ("BOOTP: Bootstrap Protocol"): DHCP history and DORA exchange

Lecture outline (~2 hours)

Section 1: The UDP header

UDP is 8 bytes of header:

Field Size Meaning
Source Port 2 bytes Port number of the sender (ephemeral, or well-known for servers)
Destination Port 2 bytes Port number of the target service
Length 2 bytes Length of the UDP header + payload in bytes (minimum 8)
Checksum 2 bytes Covers the UDP header, payload, and a pseudo-header from the IP layer

Then the payload follows immediately after the 8-byte header.

What UDP does NOT have: sequence numbers, acknowledgment numbers, connection state, retransmission timers, window size. A UDP packet is a standalone datagram. The application layer is responsible for any reliability it needs.

Section 2: Port numbers and well-known ports

  • Port numbers identify a service within a host. An IP address gets you to the machine; the port gets you to the right process.
  • Well-known ports (0-1023): reserved for standard services; binding them requires root/admin on most OSes
  • Registered ports (1024-49151): assigned to specific applications by IANA
  • Ephemeral ports (49152-65535, varies by OS): chosen by the OS for client-side connections

Common UDP well-known ports:

Port Protocol
53 DNS
67 DHCP server
68 DHCP client
123 NTP (Network Time Protocol)
161 SNMP (Simple Network Management Protocol)
514 Syslog

Section 3: DNS on UDP

  • DNS queries and responses: most fit in a single UDP packet (under 512 bytes, historically; up to 4096 bytes with EDNS0 extensions)
  • DNS uses TCP when responses exceed the UDP size limit or for zone transfers
  • A DNS query goes to UDP port 53 on the configured resolver
  • DNS message structure: 12-byte header (transaction ID, flags, counts) + question section + answer section (in replies)
  • Transaction ID: a 16-bit random value; the reply must echo the same ID so the sender can match it to the original query
  • The QR bit in the flags: 0 = query; 1 = response
  • Display filter: dns matches all DNS traffic; dns.flags.response == 0 for queries only; dns.flags.response == 1 for responses

Section 4: DHCP -- Dynamic Host Configuration Protocol

  • DHCP assigns IP addresses, subnet masks, default gateways, and DNS resolver addresses to hosts automatically
  • DHCP uses a 4-step exchange called DORA:
    1. DISCOVER: client broadcasts on UDP (source port 68, destination port 67, destination IP 255.255.255.255): "Is there a DHCP server? I need an IP address."
    2. OFFER: DHCP server unicasts or broadcasts an OFFER with a proposed IP address and lease time
    3. REQUEST: client broadcasts a REQUEST, confirming it wants the offered IP (broadcasts even though it got an offer, in case multiple servers replied)
    4. ACK: DHCP server confirms the assignment; client now has a valid IP address for the lease duration
  • All four packets are UDP. All use port 67 (server) and port 68 (client).
  • Display filter: dhcp.option.dhcp == 1 for DISCOVER; dhcp.option.dhcp == 2 for OFFER; dhcp.option.dhcp == 3 for REQUEST; dhcp.option.dhcp == 5 for ACK

Section 5: Why UDP for these protocols

  • DNS: single question, single answer. The overhead of TCP connection setup is larger than the query itself. If the UDP reply does not arrive, the client retries. Simplicity wins.
  • DHCP: the client does not yet have an IP address when DHCP runs, so it cannot establish a TCP connection. UDP broadcasts work at the pre-IP stage.
  • NTP, Syslog, gaming, video streaming: applications where a small amount of data loss is acceptable and low latency is important. Retransmitting old video frames would be worse than losing them.
  • When does UDP use TCP fallback? DNS over TCP for large responses; SNMP can use TCP; NTP has no TCP fallback (it just retransmits).

Labs (~90 minutes)

Lab 5-1: DHCP Handshake (labs/lab-5-1-dhcp.md) Lab 5-2: DNS Query and Response (labs/lab-5-2-dns.md)

Independent practice (~7 hours)

  1. Read Stevens Ch 11 in full; work through the checksum example if one is present
  2. Load fundamentals-dhcp-handshake.pcap in pcap-tools. Identify all four DORA packets. For each: what is the source port? Destination port? What is the DHCP message type option value?
  3. Load fundamentals-dns-query.pcap. Expand the DNS header. What is the transaction ID? What flag indicates this is a query vs a response? What record type is being requested?
  4. Run dig example.com on your machine. Compare the output to what you see in fundamentals-dns-query.pcap. Does the transaction ID match? (It will not -- dig generates a new one each time -- but the field positions will be identical.)
  5. Look up EDNS0 (RFC 6891). What problem does it solve? What is the OPT pseudo-record?

Reflection prompts (~30 minutes)

  1. DNS uses UDP by default but falls back to TCP for large responses. HTTP never uses UDP (except as HTTP/3 over QUIC). What about DNS makes UDP workable but makes UDP alone insufficient for web browsing?
  2. DHCP uses broadcast. Broadcasts are not routed across subnet boundaries. What does this mean for large corporate networks with many subnets?
  3. UDP has no connection state. This means a server responding to UDP packets has no way to verify that the source IP of a UDP packet is real (it could be spoofed). What attack does this enable? (Look up "UDP amplification attack.")
  4. NTP uses UDP and synchronizes clocks across the Internet to within milliseconds. What would break in your daily computing if NTP stopped working?
  5. The UDP length field includes the 8-byte header. The minimum valid UDP packet has length 8 (no payload). Is a zero-payload UDP packet useful for anything?

What comes next

Week 6 introduces TCP: the reliable, ordered, connection-oriented transport. You will trace the three-way handshake step by step through a packet capture, following the sequence and acknowledgment numbers that guarantee TCP's delivery guarantee.