Rapid DHCP: Or, how do Macs get on the network so fast?

So, as far as I understand, the issue pointed out here is that the Mac is sending ARP requests with a cached source IP address (which therefore could be already in use).

I wonder why it does that, as you can also send ARP probes originating from a source IP address 0.0.0.0 (and only having the MAC address set). I just tried it on linux:

arping -D -c 1 -I wlan0 172.22.36.1

The computer with 172.22.36.1 will happily send me back its MAC address.

So, is Apple doing something else here? Maybe relying on the router to not poison its cache and not reply at all if the IP is already taken.

There are three phases here:

1st phase is networking discovery. During this phase, the Mac is sending ARP who-has requests, which are "anyone out there" requests, not, "hey, I'm using this" requests.

2nd phase is the assumption. If the DHCP client in iOS is able to verify the Ethernet and IP address of the DHCP server match it's suspected network profile, and it has a valid DHCP lease record for that network, it assigns that IP to the interface and begins using it, at which point any potential ARP poisoning would occur.

3rd phase is DHCP negotiation. The first actual DHCP request goes out at 00.0140s, which is after the initial ARP network profiling, but before the interface actually comes up, so these actions could be considered asynchronous. Once the DHCP negotiation completes, any incorrect assumptions are abandoned and the DHCP issued IP would be used.

There appears to be a window of 1.0s where the device is using an assumed IP address. During this time, traffic transmitted on the network would "poison" the ARP cache, but IP conflicts are not an end of the world scenario in networking terms. Once the proper DHCP resolution occurs, the ARP table would be updated and the conflict resolved.