[tomlogic]

Regarding your security statement, I didn't get that from the packet capture. The Mac is sending an ARP request for the IP addresses of the DHCP servers of networks it's been on recently. An attacker would need to know the correct MAC address to respond with -- the Mac is not sending that out in the request.

If the ARP comes back with the cached MAC address for that network, the Mac continues using the valid DHCP lease it was given. It sends a DHCP request to renew that lease, and I assume would reconfigure the interface if the request fails and discovery has to start over.

From my recollection of the DHCP RFC, if a server hands you a lease for one week, you're allowed to use that address for a week, even if you go offline for 3 days in the middle. In practice, this may not be the case.

[cbs]

the Mac is not sending that out in the request.

I could be wrong about this, as I haven't analyzed actual arp requests in ages, but from the article it appears the arp requests are unicast to the (at least in the example) cached MAC for the gateway.

[tomlogic]

Ah, after a closer look at the original article, I see that now. Curious that Apple would choose to unicast those requests.

[caf]

It does this to verify that the DHCP server has the same MAC address as the one that it remembers. If the server that it remembers isn't present on the current network, the unicast packet should be ignored.