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

(cafbit.com)

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]▶

>>2755677 #

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]▶

>>2756755 #

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 #

1. deskamess ◴[12 Jul 11 23:05 UTC] No.2757020[source]▶

>>2756799 #

I think your description is correct.

The problem is the impact of the false "ip conflict" that is caused by this optimization. A device that detects an ip conflict should not have to guess whether it is an ip conflict caused by an optimization on another device. As pointed out in other comments an ip conflict can cause other systems to drop existing connections.

No one likes ip conflict notifications, or to have their connections dropped. Play nice. That's all.

replies(2): >>2757170 #>>2757512 #

2. rlpb ◴[13 Jul 11 00:00 UTC] No.2757170[source]▶

>>2757020 (TP) #

The problem is that the DHCP server re-issued a valid lease to a second computer. Surely this is an issue with the DHCP server not playing nice, rather than Apple?

replies(2): >>2757230 #>>2757709 #

3. jarek ◴[13 Jul 11 00:20 UTC] No.2757230[source]▶

>>2757170 #

Do you feel there is a better, more tolerant, and less error prone course of action the DHCP server could take if it runs out of leases?

replies(1): >>2757499 #

4. rlpb ◴[13 Jul 11 02:09 UTC] No.2757499{3}[source]▶

>>2757230 #

If we are able to modify the DHCP server to do something sensible, why not modify default router settings to issue /16 addresses instead of /24? Or even 10/8? There's plenty of RFC1918 space to not run out.

NAT state tables won't have to stretch that far as they can time out unused connections just like they do already.

Would there be any unintended side-effects with doing this?

If you don't like the NAT, go ahead and issue IPv6 :-)

5. tzs ◴[13 Jul 11 02:14 UTC] No.2757512[source]▶

>>2757020 (TP) #

This optimization does not cause IP address conflicts. If a DHCP server is not correctly keeping track of lease times and ensuring that addresses already assigned are not reused while the client still has a valid lease, you can get IP conflicts regardless of whether or not their are any Apple devices on the network.

6. hristov ◴[13 Jul 11 03:53 UTC] No.2757709[source]▶

>>2757170 #

Not really. The DHCP server may have many valid reasons for reissuing a technically valid lease, such as it being restarted and losing its table of valid leases. As I pointed out in a response above, the DHCP protocol makes it clear that devices should re-verify their addresses after waking up.

↑