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

Re:Rapid DHCP: Or, how do Macs get on the network so fast? by tomlogic on Tuesday July 12, 2011 @03:54PM (#2756245)

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.

[ Parent | on HN ]

Re:Rapid DHCP: Or, how do Macs get on the network so fast? by cbs on Tuesday July 12, 2011 @04:36PM (#2756437)

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.

[ Parent | on HN ]

Re:Rapid DHCP: Or, how do Macs get on the network so fast? by tomlogic on Tuesday July 12, 2011 @08:18PM (#2757225)

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

[ Parent | on HN ]

Re:Rapid DHCP: Or, how do Macs get on the network so fast? by caf on Wednesday July 13, 2011 @01:49AM (#2757942)

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.

[ Parent | on HN ]