←back to thread

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

(cafbit.com)
354 points timdoug | 2 comments | 12 Jul 11 17:04 UTC | HN request time: 0.001s | source
Show context
saurik ◴[12 Jul 11 17:52 UTC] No.2755677[source]▶
> This network recognition technique allows the Mac to very rapidly discover if it is connected to a known network. If the network is recognized (and presumably if the Mac knows that the DHCP lease is still active), it immediately and presumptuously configures its IP interface with the address it knows is good for this network.

Ok, seriously? That isn't a bug in an implementation somewhere, but in fact a feature that Apple actually is proud of? Am I the only one who finds that if you get a room full of people sitting around with Macs at least one person gets their IP address stolen by someone else?

(edit: I just got downvoted, and then asked the people in the room with me, and they seemed to agree with my perceived correlation regarding the "another computer is using 192.1.0.1" issue... instead of just downvoting, maybe reply? It is actually quite common that DHCP leases on a network get reset for various reasons, and if you just jump on the network without revalidating your lease, you are actually quite likely to just "presumptuously" steal someone else's IP address.)

replies(11): >>2755698 #>>2755761 #>>2755851 #>>2756177 #>>2756303 #>>2756333 #>>2756755 #>>2757385 #>>2758088 #>>2758576 #>>2758677 #
sedev ◴[12 Jul 11 21:48 UTC] No.2756755[source]▶
I think that you're wrong because, basically, if that 'steal an IP address' scenario happens, it means that the DHCP server has in some way broken its promises. That _happens_ in production environments, but I'd much rather clients use behavior like this, that assumes that a DHCP server will keep its promises about things like lease length, than assume the worst about the DHCP server. The clients should first assume that the server will keep its promises, and only on evidence that it hasn't, seek alternatives.
replies(2): >>2756799 #>>2757700 #
jarek ◴[12 Jul 11 21:59 UTC] No.2756799[source]▶
So here's my understanding of the situation: when a DHCP server runs out of leases to assign, it will kill the oldest (in terms of use) lease. If the device that held the lease is not on, for relevant values of "on", at the time, it will not be notified about this.

The usual (perhaps standard, I'm not sure) process has the device confirming its DHCP lease when coming back on, and in this situation the device would be notified that it can't have the old lease as it's been repurposed, and the server will provide another lease (perhaps after killing some yet another lease).

If this is an Apple device and it behaves in the manner described, after coming back "on" it will not consult DHCP, but rather it will reuse the lease it held previously. If the server has given that lease to another device, the Apple device will butt in, causing an IP conflict. Perversely, the Apple device will shortly discover this, actually do a DHCP request, and switch over with no indication to the user, leaving the other device to wonder why it had an IP conflict and how to handle it.

Is this incorrect in any way?

replies(3): >>2756984 #>>2757020 #>>2757447 #
tzs ◴[12 Jul 11 22:55 UTC] No.2756984[source]▶
As far as I can see from the RFC and from Googling, there is no mechanism for a DHCP server to take back an IP address before the lease has expired, unless the client explicitly initiates relinquishing the lease.

Once the address is given out, it is the client's for the term of the lease.

replies(2): >>2757027 #>>2757219 #
1. sedev ◴[13 Jul 11 00:15 UTC] No.2757219[source]▶
That's where I'm at with this. What Jarek describes can happen, but that's a failure case, not the normal-operation case. And as portrayed in the article, the engineers at Apple have accounted for the failure case, so all's well. They simply have made the very reasonable assumption that the DHCP server will normally be operational, not in a crisis state, and that it will honor its contracts as specified in the RFC. How hard is this?
replies(1): >>2757305 #
2. jarek ◴[13 Jul 11 00:48 UTC] No.2757305[source]▶
There is that principle of "conservative in what you send, liberal in what you accept" on which UNIX and half of the internet was built.