Build1 publisher3 min readPublished
Windows Server 2025 offered a squatted address 406 microseconds after the DISCOVER
The Conflict detection attempts setting under IPv4 Advanced still defaults to 0 on Windows Server 2025 build 26100.33296. A packet capture from a sealed three-VM lab shows the offer leaving with no probe behind it.
The Engineer · Build desk
What happened
- Windows Server 2025 still ships the Conflict detection attempts setting, under IPv4 Properties then Advanced, at a default of 0, so the DHCP server offers addresses it has never probed.
- In a three-VM lab the server handed out an occupied 172.16.0.10 some 406 microseconds after the request, without sending a single ICMP packet or ARP frame from its MAC in the capture.
- The client ARP-probed the address, the squatter answered, and 3.1 seconds after the ACK the client sent DHCPDECLINE and fell back to 169.254.248.228 with no default gateway.
- After one PowerShell change set conflict detection to 2, the server probed 481 microseconds after the DISCOVER, found the address taken, and issued no offer across nine DISCOVERs.
Compiled by The EngineerSomething wrong?How this is made
Why it matters
- decision The zero stays zero until someone types otherwise, and the server side gives no warning: the first report of the conflict is a user whose machine has no network.
- constraint Enabling the server probe narrows the window without closing it, because both checks treat silence as free and a powered-off or sleeping occupant is scored absent.
- exposure Devices whose stacks never send an ARP probe have no client-side check to fall back on, so they are the population that ends up holding a genuine duplicate.
- cost Each conflict costs one boot now and another every lease period after, roughly 45 a year at an 8-day lease, until someone finds the host squatting on the address.
RFC 2131 splits the check across both ends of the transaction. The dev.to write-up quotes it: "the allocating server SHOULD probe the reused address before allocating the address, e.g., with an ICMP echo request, and the client SHOULD probe the newly received address, e.g., with ARP." [4] Both halves are SHOULD, and neither is MUST [5]. Microsoft implemented both and ships the server half turned off [6].
Because the client half works, the usual outcome is a single host with no network, beside a DHCP server that has just told it everything is fine [13]. That is also why the ticket looks unfalsifiable: service running, no errors in the event log, free addresses in the scope, and a reboot that clears it [2]. The author reports first seeing this on Windows Server 2003 and assuming it had been fixed [3].
Server-side ICMP and client-side ARP are the same bet, that silence means the address is free [16]. An occupant that is powered off, asleep, on a link that is momentarily down, or behind a fabric that suppresses ARP gets scored as absent, and the duplicate surfaces later when that host wakes up and starts answering for an address someone else now holds [15]. Embedded devices, IoT gear and older or minimal stacks never probe at all, so they keep the duplicate [14].
After a decline the server keeps one lease-table row marked BAD_ADDRESS [17]. Its Unique ID field holds 0a0010ac. The value is 172.16.0.10 written as little-endian hex, not a client MAC [18]. Neither the claimant nor the reporter is recorded, so tracing the squatter means going to the switch or capturing packets [18].
The change is one line: Set-DhcpServerv4Setting -ConflictDetectionAttempts 2 [19]. In the rerun the probe left 481 microseconds after the DISCOVER, 75 microseconds later than the unprobed server had taken to answer [1]. The unmeasured cost is the timeout spent waiting for a reply that never comes, and the write-up gives probe timings without the per-attempt timeout [21].
Two conditions have to hold before those microsecond figures mean anything on a production network. The timings came from three VMs on a VMware Workstation LAN Segment, a virtual switch with no uplink and no host interface, so ARP and ICMP travel the shortest path they ever will [7]. And the scope was deliberately cut to one address, 172.16.0.10, with an 8-day lease [8]. On that bench, refusing to offer left the server with nothing to give: nine DISCOVERs, zero OFFERs [20]. For refusal to turn into a normal lease instead of a silent client, the scope needs spare addresses the server can move to.
The BAD_ADDRESS row is temporary. It expires on the scope lease duration, 8 days as configured, and if the squatter is still there the address returns to the pool, gets offered, gets declined and gets marked again, one failed boot per round [17]. At 8 days a cycle, that is about 45 rounds in a year [2].
What to watch
- A measured per-attempt probe timeout would price what turning detection on costs offer latency on a busy scope.
- Whether Microsoft changes the shipped default in a build after 26100.33296, or leaves the server half at 0.
- Whether the same capture reproduces on a physical switch rather than a VMware Workstation LAN Segment with no uplink.