←back to thread

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

(cafbit.com)
354 points timdoug | 1 comments | 12 Jul 11 17:04 UTC | HN request time: 0s | 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 #
hristov ◴[13 Jul 11 03:49 UTC] No.2757700[source]▶
Being a dork and a lawyer, I actually looked up the DHCP protocol. This is the relevant part:

"3.7 When clients should use DHCP

   A client SHOULD use DHCP to reacquire or verify its IP address and
   network parameters whenever the local network parameters may have
   changed; e.g., at system boot time or after a disconnection from the
   local network, as the local network configuration may change without
   the client's or user's knowledge.

   If a client has knowledge of a previous network address and is unable
   to contact a local DHCP server, the client may continue to use the
   previous network address until the lease for that address expires.
   If the lease expires before the client can contact a DHCP server, the
   client must immediately discontinue use of the previous network
   address and may inform local users of the problem."
So no there is no indication in the protocol that the clients should assume that the DHCP server will keep its promises after a disconnection from the network. Furthermore, if you use common sense there is no reason to make this assumption in most real life situations. In a coffee house somebody can always trip over the router's cable, for example.
replies(2): >>2757723 #>>2757771 #
pacala ◴[13 Jul 11 04:01 UTC] No.2757723[source]▶
The small print in paragraph 2 explicitly allows reusing the previous address until the lease expires.
replies(1): >>2757740 #
hristov ◴[13 Jul 11 04:09 UTC] No.2757740[source]▶
Paragraph 2 only allows this "If a client ... is unable to contact a local DHCP server." Note that in the present example, the client started using its old address before even trying to contact the DHCP server and eventually was able to contact the DHCP server.
replies(1): >>2757894 #
1. wnoise ◴[13 Jul 11 05:35 UTC] No.2757894[source]▶
This could alternately be described as "a client used its old address until it could contact the DHCP server".