UDP // RFC 768

The minimal transport protocol: two ports, a length and a checksum. UDP adds multiplexing and error detection, then gets out of the way. It is the substrate for DNS, DHCP, NTP, QUIC and most of the traffic that would rather have low latency than a handshake.

RFC 768 · UDP RFC 8200 · IPv6 checksum RFC 8085 · UDP usage IANA ports 8 B header ports · length · checksum pseudo-header

layer transport header 8 B fixed length 8–65535 B checksum IPv4 optional · IPv6 mandatory

layout
ports
checksum
encode
decode
notes

01Datagram layout

eight bytes of header · then payload

A UDP datagram is an 8-byte header followed by data. Source Port and Destination Port identify the sending and receiving endpoints; Length counts the header plus data; Checksum covers a pseudo-header, the UDP header and the data. The IP layer supplies the source and destination addresses used by the pseudo-header.

Length includes the header

A UDP datagram with no payload has Length = 8. The maximum is 65535, and the data field is therefore at most 65527 bytes before IP-level limits. The IP payload may be larger than the UDP Length only if there is trailing data, which is malformed for ordinary UDP.

02Ports & services

16-bit endpoints · 0–65535

A UDP flow is identified by a four-tuple: source address, source port, destination address and destination port. Ports 0–1023 are the system or well-known range; 1024–49151 are user/registered ports; 49152–65535 are dynamic or private ports. The source port is often ephemeral, while the destination port names the service.

port classifierservice names and ranges

source port 0–65535

53000 · dynamic / private

destination port 0–65535

53 · DNS

socket pair 53000 → 53 destination service DNS

Port names are conventions from the IANA service registry. They do not prove that the payload is valid for that service, and a server can bind any port it likes.

Port	Service	Typical use	Notes
`53`	DNS	Queries and responses	Also TCP/53 for large responses and zone transfers.
`67/68`	DHCP	Server / client	Broadcast before the client has an address.
`69`	TFTP	Trivial file transfer	The server replies from a new ephemeral port.
`123`	NTP	Time synchronization	Client source port is usually 123 as well.
`137/138`	NetBIOS	Name and datagram service	Legacy Windows local-network discovery.
`161/162`	SNMP	Poll / trap	Agents listen on 161, managers receive traps on 162.
`500/4500`	IKE / IPsec NAT-T	Key exchange	4500 is used when NAT-T encapsulation is active.
`514`	syslog	Log transport	UDP syslog is fire-and-forget; TCP/TLS add reliability.
`520`	RIP	Routing updates	Distance-vector routing over UDP/520.
`546/547`	DHCPv6	Client / server	IPv6 configuration; link-local multicast is common.
`1900`	SSDP	UPnP discovery	Multicast discovery on the local network.
`4789`	VXLAN	Overlay encapsulation	Carries Ethernet frames over UDP.
`5353`	mDNS	Local name resolution	Multicast DNS, often paired with DNS-SD.
`6081`	Geneve	Overlay encapsulation	Extensible tunnel metadata over UDP.
`33434+`	traceroute	Path discovery	Classic Unix traceroute increments destination UDP ports.

UDP is a reflection target

The source address is not authenticated. Any protocol that sends a large response to a spoofed source can be used for amplification. Rate limiting, response-size checks and ingress filtering are operational controls, not UDP features.

03Length & checksum

pseudo-header · IPv4 vs IPv6

The UDP checksum is the one's-complement sum of a pseudo-header, the UDP header and the UDP data. The pseudo-header binds the datagram to its IP source and destination so a misdelivered packet is rejected. IPv4 makes the checksum optional: a transmitted zero means “no checksum.” IPv6 makes it mandatory, and a zero checksum is invalid.

Context	Pseudo-header	Checksum rule	Reference
IPv4	Source 4 B + destination 4 B + zero 1 B + protocol 1 B (`17`) + UDP Length 2 B = 12 B	Optional. A checksum field of zero means the sender did not compute one. A computed zero is transmitted as `0xFFFF`.	RFC 768 · RFC 1071
IPv6	Source 16 B + destination 16 B + UDP Length 4 B + three zero bytes + next header 1 B (`17`) = 40 B	Mandatory. Zero is invalid; a computed zero is transmitted as `0xFFFF`.	RFC 8200 §8.1

the checksum is not a MAC

A valid UDP checksum proves that the pseudo-header, header and payload survived the path without accidental corruption under the sender's computation. It does not prove who sent the datagram, and NAT devices may need to rewrite it when they change addresses or ports.

04Encoder

length auto · checksum with IP context

Build a UDP datagram and compute its checksum with an IPv4 or IPv6 pseudo-header. The output can be the raw UDP datagram or a complete IP packet. The source and destination addresses are context, not UDP header fields; they matter only for the checksum and the optional wrapper.

UDP parameters

RFC 768

source port 0–65535

53000 · dynamic / private

destination port 0–65535

53 · DNS

presets

IP context

output

TTL / hop limit 0–255

IPv4 source

IPv4 destination

zero checksum (IPv4)

length auto

checksum auto

data encoding

payload

The checksum is computed over the pseudo-header selected by the IP context, the full UDP header and the payload. Length is calculated as 8 + payload bytes. The full-packet output wraps the datagram in IPv4 or IPv6 using the addresses above.

wire output

waiting

Set the fields and press Build UDP.

datagram / packet hex

no bytes built yet

a checksum needs a context

The UDP header does not contain IP addresses. If you copy the raw datagram without its source and destination, a receiver cannot recompute the checksum from the bytes alone. Keep the IP context when you paste it into a lab tool.

05Decoder

raw UDP · IPv4 · IPv6 · Ethernet

Paste a raw UDP datagram, an IPv4 packet with Protocol 17, an IPv6 packet whose terminal Next Header is 17, or an Ethernet frame carrying either. The decoder validates the UDP checksum when it can see the IP context. Raw UDP is parsed but its checksum is marked as not checkable.

parse bytes

RFC 768 · checksum context

hex input UDP, IPv4/IPv6 packet or Ethernet frame

input type

No UDP datagram decoded yet.

06Wire notes

minimal by design

UDP is a multiplexing layer, not a reliable transport

UDP provides ports and an optional checksum. It does not provide connection setup, sequencing, retransmission, flow control or congestion control. Applications that need reliability build it above UDP, as QUIC does, or use TCP instead.

Length counts the header. A zero-payload datagram has Length 8. If the IP payload is longer than the UDP Length, the extra bytes are not part of the UDP datagram; ordinary UDP should not include them.
The checksum includes a pseudo-header. IPv4 uses a 12-byte pseudo-header; IPv6 uses 40 bytes. The UDP Length field participates, so rewriting lengths without updating the checksum breaks it.
Zero checksum is context-dependent. In IPv4 it means “not computed.” In IPv6 it is invalid. A computed checksum of zero is transmitted as 0xFFFF.
NAT rewrites checksums. A NAT that changes an address or port must recompute the UDP checksum. Captures taken at different points on the path can legitimately disagree.
Fragmentation is an IP concern. UDP has no fragment fields. IPv4 may fragment at routers; IPv6 uses a Fragment extension header and source-based fragmentation. A decoder needs the first fragment to see the UDP header.
Port numbers are not authentication. A source port is a claim, not an identity. UDP reflection and spoofing are common because there is no handshake.
UDP-Lite is different. UDP-Lite changes the length field semantics and allows partial checksum coverage. It uses IP protocol 136, not UDP protocol 17; do not parse it with a UDP assumption.

References

RFC 768UDP
RFC 1071Internet checksum
RFC 8200IPv6 and mandatory UDP checksum
RFC 8085UDP usage guidelines
RFC 6936UDP zero checksum
RFC 3828UDP-Lite
IANA registryservice names and ports

next protocol DNS records & name compression ->