rfc-visual
GitHub

RFC 2131 · March 1997 · R. Droms

Dynamic Host Configuration Protocol

DRAFT STANDARDIETF stream
7 verified errata2 held for document update

Index fetched 2026-10-19 from rfc-editor.org

How it works

Built by hand from RFC 2131. Every arrow, step and field cites the RFC sentence it comes from, and an automated test checks each quote against the RFC text. Provisional: not yet reviewed by a second engineer. Help verify this visual

100%

RFC 2131 §3.1 The timeline diagram in figure 3 shows the timing relationships in a typical client-server interaction.

  1. 1. Client → Server: DHCPDISCOVER

    The client broadcasts a DHCPDISCOVER on its local subnet to locate available servers. Relay agents may pass it on to servers on other subnets.

    RFC 2131 §3.1 The client broadcasts a DHCPDISCOVER message on its local physical subnet.

  2. 2. Server → Client: DHCPOFFER

    A server may answer with a DHCPOFFER that carries an available address in 'yiaddr' plus other configuration in options.

    RFC 2131 §3.1 Each server may respond with a DHCPOFFER message that includes an available network address in the 'yiaddr' field (and other configuration parameters in DHCP options).

  3. 3. Client → Server: DHCPREQUEST

    The client picks one offer and broadcasts a DHCPREQUEST naming the chosen server in the 'server identifier' option. Servers not chosen take it as a decline.

    RFC 2131 §3.1 The client broadcasts a DHCPREQUEST message that MUST include the 'server identifier' option to indicate which server it has selected, and that MAY include other options specifying desired configuration values.

  4. 4. Server → Client: DHCPACK

    The chosen server commits the lease binding to persistent storage and replies with a DHCPACK holding the configuration. The client is then configured.

    RFC 2131 §3.1 The server selected in the DHCPREQUEST message commits the binding for the client to persistent storage and responds with a DHCPACK message containing the configuration parameters for the requesting client.

Not shown: INIT-REBOOT and REBOOTING (reusing a known address, sections 3.2 and 4.4.2): Figure 5 has no transition into INIT-REBOOT from the states shown, so they cannot be placed on the path from INIT; Failure paths back to INIT from REQUESTING (DHCPNAK, DHCPACK not acceptable / send DHCPDECLINE) and from RENEWING and REBINDING on DHCPNAK, which appear only in Figure 5 and are not tied to their source state in the prose; Messages that Figure 5 shows being collected or discarded without a state change; DHCPNAK, DHCPDECLINE, DHCPRELEASE and DHCPINFORM exchanges; Server behaviour (address selection, lease commitment, section 4.3) and relay agents; Retransmission timing, the T1 and T2 default values, and the BROADCAST flag rules (section 4.1); Contents of individual options.

Lineage

100%

Text

Loading the RFC text…