I wonder if Apple has a patent on this technique.
Rapid DHCP: Or, how do Macs get on the network so fast?
101–110 of 191 posts
Re: Rapid DHCP: Or, how do Macs get on the network so fast?
#102Does anyone remember this? Princeton Information Technology: "iPhone OS 3.2 on iPad Stops Renewing DHCP Lease, Keeps Using IP Address" http://www.net.princeton.edu/announcements/ipad-iphoneos32-s...
Very interesting. It sounds like they had some troubles getting this to a properly working state.
Re: Rapid DHCP: Or, how do Macs get on the network so fast?
#103Congratulations! Your laptop does the equivalent of using the exit lane to jump ahead in traffic. There's bound to be an empty spot near the end, right?
The only reason that is a useful example to you is because that act is genuinely dangerous. There is nothing dangerous about swiping someone's IP and causing them to have to reconnect.
You're right. I guess it's more comparable to walking up to a checkout or a cash register without looking to see if anyone is waiting in line. Great UX if you don't look around you.
Re: Rapid DHCP: Or, how do Macs get on the network so fast?
#104Earlier quoted context omitted.
I ask again: do you have any evidence that this is a problem in practice? I feel like this is something we would have heard about before, via some outraged blog post followed by Apple discussion board postings that get deleted by Apple. How often do computers send out ARP requests to check on the uniqueness of their IP address? If it's less often than once per second or so (and I really hope it is), I could see how y…
...do you have any evidence that this is a problem in practice? When iPhone OS first came out, there was a bit of an uproar on many university campus networks that they were seriously screwing up the behavior of DHCP on networks with a very large number of transient clients.
Re: Rapid DHCP: Or, how do Macs get on the network so fast?
#105Earlier quoted context omitted.
Proprietary in the computer sense is generally taken to mean closed source or at least not made available to competitors or others. There's nothing to stop any other systems offering this kind of quick start DHCP service.
Except that it violates the specification right? I guess we're agreeing to disagree on the definition of proprietary. I can buy all of Apple's funky connectors through various suppliers, and maybe even fab them myself, but to me they're still proprietary. Sorry to be pedantic!
Which specification does it violate?
Re: Rapid DHCP: Or, how do Macs get on the network so fast?
#106Earlier quoted context omitted.
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.
Given that most routers are managing a class C network, and even then have allocated the first 100 addresses for internal use (starting the DHCP pool at .100), this would mean that it would be trivial to DoS any DHCP server in seconds by simply cycling MAC addresses and leasing all of their addresses. Obviously, this is not realistic, and no one would ever implement a DHCP server that allowed this to happen: it is go…
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 assumed that a competent systems administrator managed the server and could manually respond to running out of available addresses (which was considered a likely sign of misconfiguration), and didn't attempt to specify what to do in the case where it happens.
Not giving out an address and notifying the systems administrator is what the DHCP spec recommends in this case. In fact, section 2.2 claims "The allocation mechanism (the collection of DHCP servers) guarantees not to reallocate that address within the requested time" so any reclamation of IP address on the part of the server is technically in violation of RFC 2131.
Re: Rapid DHCP: Or, how do Macs get on the network so fast?
#107Earlier quoted context omitted.
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…
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?
Re: Rapid DHCP: Or, how do Macs get on the network so fast?
#108Earlier quoted context omitted.
Except that it violates the specification right? I guess we're agreeing to disagree on the definition of proprietary. I can buy all of Apple's funky connectors through various suppliers, and maybe even fab them myself, but to me they're still proprietary. Sorry to be pedantic!
Which specification does it violate?
rfc 2131? seems to say the client can ask for an unlimited lease, but the server can specify a finite one. this article seems to be saying that this thing will use the last one leased no matter how long it's been off the network
Re: Rapid DHCP: Or, how do Macs get on the network so fast?
#109Earlier quoted context omitted.
I'd like to see evidence that this happens enough to matter. Any time you use a Bloom filter you recognize that doing great in most cases is much better than doing OK in every case.
What does a bloom filter have to do with this? Generally when someone uses a probabilistic data structure, they ensure its used in a manner that becomes consistent (e.g., as a caching layer). If by not following the dhcp spec, macs are breaking other peoples' connectivity, there's no recovery save them disabling/reenabling the network for them manually.
First, they don't break the DHCP spec -- everything they do is completely within spec. Second, ARP resolution doesn't require any manual resolution. Third, show me that the OS X ARP system is breaking other peoples' connectivity.
The Bloom filter was an analogy. Optimize for the common case, not the rare case.
Re: Rapid DHCP: Or, how do Macs get on the network so fast?
#110Earlier quoted context omitted.
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.
Given that most routers are managing a class C network, and even then have allocated the first 100 addresses for internal use (starting the DHCP pool at .100), this would mean that it would be trivial to DoS any DHCP server in seconds by simply cycling MAC addresses and leasing all of their addresses. Obviously, this is not realistic, and no one would ever implement a DHCP server that allowed this to happen: it is go…
It's trivial to DoS any layer 2 network. This is trivial netsec.