DHCP // RFC 2131
DHCP gives a host an IPv4 address and the configuration that goes with it: routes, DNS servers, a lease lifetime and more. The packet is a BOOTP header followed by a magic cookie and a list of type-length-value options.
01Message layout
BOOTP fixed header · magic cookie · options
Every DHCPv4 message starts with the 236-byte BOOTP header. The first four octets
identify the operation and the client hardware address type; the next fields carry
the transaction ID, timing, flags and four IPv4 addresses. A DHCP message then adds
the magic cookie 63 82 53 63 and the option area.
| Field | Offset | Width | Meaning | Reference |
|---|---|---|---|---|
| op | 0 | 1 B | 1 = BOOTREQUEST (client), 2 = BOOTREPLY (server). | RFC 2131 §2 · RFC 951 |
| htype | 1 | 1 B | Hardware type. 1 is Ethernet. | RFC 2131 §2 · RFC 1700 |
| hlen | 2 | 1 B | Hardware address length in bytes; normally 6. | RFC 2131 §2 |
| hops | 3 | 1 B | Relay hop count, set by relay agents. | RFC 2131 §2 |
| xid | 4 | 4 B | Transaction identifier, chosen by the client and echoed by the server. | RFC 2131 §2 |
| secs | 8 | 2 B | Seconds elapsed since the client began address acquisition. | RFC 2131 §2 |
| flags | 10 | 2 B | Broadcast bit (0x8000); remaining bits reserved and zero. | RFC 2131 §2 · RFC 2132 §2 |
| ciaddr | 12 | 4 B | Client IP address, filled in by a client that already has one. | RFC 2131 §2 |
| yiaddr | 16 | 4 B | “Your” IP address offered by the server. | RFC 2131 §2 |
| siaddr | 20 | 4 B | Next server address for bootstrap; often the DHCP server or TFTP server. | RFC 2131 §2 |
| giaddr | 24 | 4 B | Relay agent address; zero when no relay is involved. | RFC 2131 §2 |
| chaddr | 28 | 16 B | Client hardware address, padded to 16 bytes. | RFC 2131 §2 |
| sname | 44 | 64 B | Optional server host name, null-terminated. May be overloaded with options. | RFC 2131 §2 · RFC 2132 §9.3 |
| file | 108 | 128 B | Boot file name, null-terminated. May be overloaded with options. | RFC 2131 §2 · RFC 2132 §9.3 |
| magic cookie | 236 | 4 B | 63 82 53 63 (0x63825363), marking the DHCP option area. | RFC 2131 §3 |
| options | 240 | var | TLV options, terminated by option 255. Pad with option 0. | RFC 2132 |
The flags word
A DHCP message is at least 240 bytes once the magic cookie is present. The option area carries the message type, addresses, lease timers and every other parameter. A message with no option 53 is BOOTP-shaped but cannot identify itself as DHCP.
02Message types
option 53 · one byte · eight standard messages
The DHCP message type lives in option 53. It is one byte and must be present
in every DHCP message. The standard exchange is DISCOVER → OFFER → REQUEST → ACK;
NAK rejects a request, while RELEASE and DECLINE are client notifications.
| Code | Message | Direction | Purpose | Reference |
|---|---|---|---|---|
1 | DISCOVER | C → S | Client broadcasts a request for an address; yiaddr is zero. | RFC 2131 §4.3.1 |
2 | OFFER | S → C | Server offers an address and configuration in yiaddr. | RFC 2131 §4.3.2 |
3 | REQUEST | C → S | Client requests an offered address or renewal; option 50 and/or option 54 identify the choice. | RFC 2131 §4.3.2 |
4 | DECLINE | C → S | Client reports that an offered address is already in use. | RFC 2131 §4.3.3 |
5 | ACK | S → C | Server commits the lease and returns the final configuration. | RFC 2131 §4.3.3 |
6 | NAK | S → C | Server rejects a request, often because the address is no longer valid. | RFC 2131 §4.3.4 |
7 | RELEASE | C → S | Client gives up its lease and returns the address to the server. | RFC 2131 §4.4.1 |
8 | INFORM | C → S | Client already has an address and asks only for configuration parameters. | RFC 2131 §4.3.5 |
Any host on the link can answer a DISCOVER. Rogue DHCP servers, spoofed ACKs and malicious option 82 data are operational security problems. DHCP snooping, port security and trusted relay ports are network controls, not protocol features.
03Options
code · length · value · end
Options are one-byte code and one-byte length TLVs. Code 0 is a one-byte
Pad; code 255 is a one-byte End. A zero-length option is valid only when the
option definition allows it. Repeated options are concatenated in the order they appear
(RFC 3396).
| Code | Option | Length | Meaning | Reference |
|---|---|---|---|---|
0 | Pad | 1 | Alignment padding; no length or value. | RFC 2132 §3.1 |
255 | End | 1 | End of the option area. | RFC 2132 §3.2 |
1 | Subnet Mask | 4 | Client subnet mask. | RFC 2132 §3.3 |
3 | Router | 4n | Default gateway addresses, in preference order. | RFC 2132 §3.5 |
6 | Domain Name Server | 4n | DNS resolver addresses. | RFC 2132 §3.8 |
12 | Host Name | n | Client host name. | RFC 2132 §3.14 |
15 | Domain Name | n | DNS domain suffix. | RFC 2132 §3.17 |
28 | Broadcast Address | 4 | Broadcast address for the client subnet. | RFC 2132 §5.3 |
50 | Requested IP Address | 4 | Address requested in a DHCPREQUEST. | RFC 2132 §9.1 |
51 | IP Address Lease Time | 4 | Lease lifetime in seconds. | RFC 2132 §9.2 |
52 | Option Overload | 1 | 1 = file, 2 = sname, 3 = both contain options. | RFC 2132 §9.3 |
53 | DHCP Message Type | 1 | DISCOVER, OFFER, REQUEST, DECLINE, ACK, NAK, RELEASE or INFORM. | RFC 2132 §9.6 |
54 | Server Identifier | 4 | DHCP server address; required in OFFER, ACK and NAK. | RFC 2132 §9.7 |
55 | Parameter Request List | n | Options the client wants the server to return. | RFC 2132 §9.8 |
56 | Message | n | Diagnostic text, often in a NAK. | RFC 2132 §9.9 |
57 | Maximum DHCP Message Size | 2 | Largest DHCP message the client accepts. | RFC 2132 §9.10 |
58 | Renewal Time Value | 4 | Time until the client moves to RENEWING. | RFC 2132 §9.11 |
59 | Rebinding Time Value | 4 | Time until the client moves to REBINDING. | RFC 2132 §9.12 |
60 | Vendor Class Identifier | n | Vendor or platform identity. | RFC 2132 §9.13 |
61 | Client Identifier | n | Stable client identity; type byte plus identifier bytes. | RFC 2132 §9.14 · RFC 6842 |
66 | TFTP Server Name | n | Bootstrap server name. | RFC 2132 §9.4 |
67 | Bootfile Name | n | Boot file path. | RFC 2132 §9.5 |
82 | Relay Agent Information | n | Relay-added sub-options such as circuit-id and remote-id. | RFC 3046 |
121 | Classless Static Route | n | Destination prefix, prefix length and next-hop. | RFC 3442 |
249 | Microsoft Classless Route | n | Microsoft encoding of classless static routes. | RFC 3442 · Microsoft |
When option 52 is present, the server may place additional options in the
file field (bit 1), the sname field (bit 2), or both (bit 3).
RFC 3396 allows a single option to be split across multiple occurrences; a decoder must
concatenate the values in order before interpreting them.
04Encoder
BOOTP header · common options · arbitrary TLVs
Build a DHCP message with a valid BOOTP header, magic cookie and option area. The
message type is always emitted as option 53. Common lease fields have dedicated inputs;
everything else can be supplied as one code = value option per line.
DHCP parameters
RFC 2131 · RFC 2132Options can use numeric codes or names such as subnet-mask, router, dns, requested-ip, parameter-request-list, client-id, relay-agent and classless-route. Duplicate code 53 is generated from the message-type selector.
wire output
waitingno bytes built yet
The output starts at the BOOTP op byte and includes the magic cookie
and option area. The decoder accepts raw DHCP, UDP, IPv4 or Ethernet input, so you
can wrap these bytes in UDP/68→67 or UDP/67→68 for a lab test.
05Decoder
raw DHCP · UDP · IPv4 · EthernetPaste a DHCP message, a UDP datagram on ports 67/68, an IPv4 packet with protocol 17, or an Ethernet frame carrying IPv4/UDP. The decoder reports the BOOTP fields, the message type, every option TLV, overloaded options and any structural warnings.
parse bytes
RFC 2131 · BOOTP · options06Wire notes
operational details that matterThe transaction ID, client hardware address, server identifier and option 82 data are all claims. Use DHCP snooping, trusted relay ports and switch-port security to limit who can answer. A valid checksum proves only that the bytes survived the path.
- Client and server ports are fixed. Clients use UDP/68 and servers use UDP/67. The first DISCOVER is broadcast because the client does not yet have an address.
- xid is matching, not authentication. A 32-bit transaction ID lets a client discard unrelated replies. It does not prove that a reply came from a legitimate server.
- The broadcast flag is a workaround. A client that cannot receive unicast before its address is configured sets 0x8000 and asks the server to broadcast the reply.
- Lease timers are relative. Option 51 is the total lease. Options 58 and 59 are renewal (T1) and rebinding (T2) times. Servers should keep T1 < T2 < lease, but clients must tolerate unusual values.
- Option overload is legal. When option 52 is set, options may continue in
file,sname, or both. Parse those areas before declaring an option missing. - Repeated options are concatenated. RFC 3396 permits a long option to be split across multiple TLVs. Concatenate the values in order; do not keep only the first occurrence.
- Relay agent information is link metadata. Option 82 is added by a relay. A server must treat it as untrusted unless the relay is trusted, and the circuit-id format is deployment-specific.
- DHCPv6 is a different protocol. DHCPv6 uses UDP/546 and UDP/547, different message types and options, and RFC 8415. Do not parse DHCPv6 with a DHCPv4 decoder.