Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

cafbit.com

Post reply on HN
Print view View original

141–150 of 191 posts

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

#141

Post by hristov »

rlpb wrote: post #107
deskamess wrote: post #96

Earlier quoted context omitted.

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 thei…

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?

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.

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

#142

Post by pacala »

hristov wrote: post #140
sedev wrote: post #82

Earlier quoted context omitted.

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…

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'…

The small print in paragraph 2 explicitly allows reusing the previous address until the lease expires.

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

#143

Post by hristov »

pacala wrote: post #142
hristov wrote: post #140

Earlier quoted context omitted.

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'…

The small print in paragraph 2 explicitly allows reusing the previous address until the lease expires.

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.

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

#144

Post by rhubarbquid »

hristov wrote: post #140
sedev wrote: post #82

Earlier quoted context omitted.

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…

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'…

It says "SHOULD" not "MUST", so the client can assume the server will keep its promises, it's just not recommended.

    "SHOULD   This word, or the adjective "RECOMMENDED", mean that there
    may exist valid reasons in particular circumstances to ignore a
    particular item, but the full implications must be understood and
    carefully weighed before choosing a different course."
http://www.ietf.org/rfc/rfc2119.txt

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

#145

Post by hristov »

rhubarbquid wrote: post #144
hristov wrote: post #140

Earlier quoted context omitted.

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'…

It says "SHOULD" not "MUST", so the client can assume the server will keep its promises, it's just not recommended. "SHOULD This word, or the adjective "RECOMMENDED", mean that there may exist valid reasons in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different course." http://www.ietf.org/rfc/rfc2119.txt

Yes, I am aware the RFC used should and not must, but nevertheless their recommendation is clear.

And of course if that item is to be ignored "the full implications must be understood and carefully weighed before choosing a different course." Here the implications are that the device may cause other devices to drop their connections, which is a pretty severe implication, imo.

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

#146

Post by hristov »

dotBen wrote: post #4

There already exists a minimal DHCP client implementation in the Linux kernel, but it lacks certain features such as configuring the DNS nameservers. I wonder if it is possible to use the kernel-level DHCP client to instantly request the IP address while asynchronously initiating the more functional user-mode dhclient? Once dhclient is up, and the kernel DHCP client has obtained an IP address it could just pass that…

The whole kernel discussion seems to be a red herring. The reason the android device was so slow is because the DHCP server timed out twice on a DHCP request. Those two timeouts caused 10s of the 11s delay.

I think there probably was something wrong with the DHCP server configuration.

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

#147

Post by caf »

hristov wrote: post #145
rhubarbquid wrote: post #144

Earlier quoted context omitted.

It says "SHOULD" not "MUST", so the client can assume the server will keep its promises, it's just not recommended. "SHOULD This word, or the adjective "RECOMMENDED", mean that there may exist valid reasons in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different course." http://www.ietf.org/rfc/rfc2119.txt

Yes, I am aware the RFC used should and not must, but nevertheless their recommendation is clear. And of course if that item is to be ignored "the full implications must be understood and carefully weighed before choosing a different course." Here the implications are that the device may cause other devices to drop their connections, which is a pretty severe implication, imo.

Note that it doesn't say that such verification has to be done prior to recommencing use of the leased address - just that it should be done. Arguably then the described implementation follows the letter of the recommendation. Your witness, counsel.

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

#148

Post by ryannielsen »

I'd like one person who's claiming this behavior is causing networking issues, is non standard, or is a security risk to provide proof.

Suppose for a second that Apple's networking stack ruined things for other users, were in violation of standards, or insecure. They'd be lambasted. Furthermore, their users would have a sub-par experience. Bad press and, more importantly, a poor user experience are two things Apple tries to minimize. They'll only put up with bad press when they perceive it to be at the long-term benefit of their business, as with the iOS App Store. I assert this is not one of those cases.

What seems more likely is that Apple decided device connectivity and wake-from-sleep performance is paramount, and then aggressively optimize to ensure Apple devices are awake and connected as quickly as possible. Period.

Users hate waiting for a machine (or phone) to wake up and, once awake, they hate waiting for it to be usable. It seems Apple saw this pain point and decided to do something about it. And, as breaking standards compliance or introducing security risks would do nothing more than bring bad press and anger or frighten users, they almost certainly optimized in a standards-compliant and secure manner.

I'm happy to be proven wrong. In the meantime, I'm going to appreciate the attention to detail and respect the work that went into providing this experience.

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

#149

Post by caf »

saurik wrote: post #114
brigade wrote: post #106

Earlier quoted context omitted.

You don't even need to cycle MAC addresses; just send DHCPDECLINE messages for any address the server gives. DHCP requires that any address that elicits that response from a client MUST be marked unavailable, and provides no provision for it ever becoming available again. Ignoring the client is the only automatic mechanism DHCP provides for countering this. You have to remember that DHCP was written back when it was…

I'm confused... are you therefore suggesting that this is how people like Linksys should handle this problem? I fully realize that the spec was written in another time, but I don't think tzs did: he is actually citing the spec as a reason why these leases should stay around. When you go to a coffee shop, the router does not and probably should not play a chime when it has run out of DHCP leases, causing the barista t…

There are sensible options available other than violating the leases.

For example, for a highly-used access point, it would make sense to give out only very short leases - say, 10 minutes. That'd support a churn of 25 clients per minute if you're giving out addresses from a /24 (and there's no reason why you couldn't use a smaller netmask, down to /8). It'd also be sensible to ignore a single MAC address once it had more than a handful of outstanding leases.

It doesn't help with a malicious client - but then neither does breaking leases. The malicious client can cause enough address flapping to make the network completely unuseable. You really can't protect a wifi network against a malicious client trying to DoS it - there's a myriad ways to do that apart from DHCP.

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

#150

Post by wnoise »

hristov wrote: post #143
pacala wrote: post #142

Earlier quoted context omitted.

The small print in paragraph 2 explicitly allows reusing the previous address until the lease expires.

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.

This could alternately be described as "a client used its old address until it could contact the DHCP server".
Post reply on HN