Summary

  • In ordinary allocation, a DHCPACK commits the server's binding and lets a client move toward BOUND only after its final address-conflict check; it grants time-limited use, not ownership.
  • The lease clock structures authority: the client first renews with the original server, later rebinding can involve any server, and expiry requires it to stop using the configuration and return to INIT.
  • A DHCPACK sent in response to DHCPINFORM allocates no address at all, showing that the message name cannot be interpreted without the exchange and fields around it.

The moment an address starts to look permanent

A device joins a network with no usable IPv4 configuration. It broadcasts, receives an offer, asks for one proposal and finally receives DHCPACK. Almost immediately the address appears in an interface, applications connect and logs begin attaching activity to it. From the device's perspective, acknowledgement and possession arrive together.

That visible sequence encourages an ownership metaphor. Yet RFC 2131 describes a controlled allocation rather than a transfer of property. The selected server commits a binding between the client and network parameters. The client records the lease and may enter BOUND, but first it performs a final check that the offered address is not already in use. If that check detects a conflict, the client sends DHCPDECLINE and begins again. Even an affirmative server message therefore does not erase evidence from the local link.

The distinction is part of the design Ralph Droms set out as author of RFC 2131. The IETF profile for Droms says he organized the working group that designed DHCP in 1989. That history supports a precise attribution: he helped turn dynamic configuration into a standardized exchange with explicit state and time. It does not make him the sole author of every later extension, server implementation or operational convention.

A lease is authority with a clock attached

DHCP does not merely deliver an address. It supplies configuration under a lease whose duration is determined by server policy. A client may request an address or suggest a duration, but the request is not a claim the server must honor. The returned DHCPACK tells the client what the server has actually accepted.

Time then divides the relationship into recognizable states. At T1, normally halfway through the lease unless the server specifies otherwise, the client enters RENEWING and directs DHCPREQUEST toward the server that granted the lease. If no renewal succeeds, T2 normally arrives at seven-eighths of the duration. The client enters REBINDING and broadens the request so another available server can respond. T1 and T2 are relative timers, not calendar promises, and a server can provide different values.

The hard edge is expiry. If no DHCPACK extends the lease before its duration runs out, RFC 2131 requires the client to stop network processing with the address immediately, relinquish it and return to INIT. The address may later be assigned elsewhere. That rule is difficult to reconcile with permanent ownership because the protocol deliberately describes the instant at which authorized use ends.

Infinite is still not a deed

RFC 2132 defines the IP Address Lease Time option and permits all one bits to mean an infinite lease. Long or infinite leases matter operationally: they can make a device's configuration remarkably durable and reduce churn. During a valid lease, moreover, the acknowledgement is not decorative. It is real authorization from the configuration service within that administrative domain.

But duration and legal meaning are different dimensions. An infinite value has no scheduled timer expiry; it does not authenticate the human operating the client, establish rights against other networks, bind a registry, or prevent an administrator from changing the surrounding system. Calling it “ownership” imports claims that the option never encodes.

RFC 5227 keeps a separate constraint visible. IPv4 Address Conflict Detection asks a host to probe before use and to defend or abandon an address when conflicts arise. That mechanism does not overrule the DHCP server, but it prevents a server's database state from being treated as perfect knowledge of the link. Permission from one control plane and observed availability on the medium are complementary evidence.

Not every DHCPACK even contains an allocation

The cleanest warning against judging the message name alone is DHCPINFORM. A client that already has an externally configured address can use DHCPINFORM to ask for other local parameters. The responding server may send DHCPACK, but RFC 2131 says this exchange does not allocate a new address, does not check for a binding, leaves the yiaddr field empty and does not include a lease-time option.

The same message type therefore participates in two materially different acts. In the allocation state machine, DHCPACK can commit a binding. In an INFORM exchange, it returns configuration without creating one. An inventory system that treats every observed DHCPACK as proof that “this server assigned this address to this client” will manufacture false provenance.

RFC 6842 illustrates another narrow improvement. It requires servers to echo the client identifier in DHCPACK and DHCPOFFER in the circumstances it defines, helping clients match replies with their exchanges. Better message matching is useful evidence, but a client identifier is not proof of a natural person's identity and is not an ownership credential.

The server knows a binding, not the whole truth

Leasequery work in RFC 4388 exposes the server's view in especially clear terms. A server can report an address as ACTIVE, UNASSIGNED or UNKNOWN and can return the remaining duration of an active lease. The query retrieves state; it does not alter the binding. Its answer is authoritative for the server's lease database, not necessarily a complete account of every packet, device or conflicting observation on the segment.

For investigators, address attribution and address allocation must therefore remain separate propositions. A lease record can support the claim that a DHCP service authorized a client identifier to use an address over an interval. It cannot by itself prove which person held the device, that all traffic from the address came from that device, or that the same attribution is valid outside the recorded interval.

This does not make DHCP evidence weak. It makes the evidence legible. Server logs, retained lease history, client identifiers, relay information, link-layer observations, conflict-detection results and synchronized time can be joined into a stronger account. The error is not relying on DHCPACK; it is asking an acknowledgement to answer questions outside its designed scope.

Sources