If you are on a known network, your DHCP lease is still active, and network equipment is working as expected, all of these assumptions are safe. The most common failure scenario is where the DHCP server has lost its DHCP lease table. For many consumer routers, this will occur when the router is rebooted. If you have to reboot your router frequently, you should replace it. Even if you do encounter a failure mode, the error will clear a second or two later when a new address is negotiated via DHCP and the subsequent ARP update.
This is very clearly a trade-off. Devices like the iPhone and iPad are switched on and off very frequently. The difference between 10s to network ready and 0.3s to network ready is more than significant; it's monumental. This is especially true for devices whose use-pattern will involve frequent on-off usage.
If you're uncomfortable with this trade off, you should stay away from Apple devices. Personally, I'll take the 10s.
I'd also argue that any DHCP server that applies that policy of artificially limiting the IP pool by re-issuing non-expired leases is an asinine implementation.
Of course people are going to like devices that allow them to cut in line if there is a little bit of space.
Something tells me Saurik is a tad more invested at this point, it's not really as simple as "avoiding Apple devices" when you are the dev of Cydia.
How many people do you think would install that patch?
* Resolves potential IP conflicts when recovering from sleep
* Adds 10s to network availability in most situations
> They want the device to work when they turn it on.
No, it just potentially kicks off another user. I've never been unable to acquire an IP because of this practice, I've just seen other people's wireless mysteriously give up the ghost when I connect with my iPhone or Mac. I would prefer to have the aggressive device, personally.
* If you have a valid lease, there should be no conflicting IP addresses on the network
* Even if you do have a conflicting IP address, that conflict only exists until the DHCP server issues you a new one (iOS immediately performs the DHCP request after sniffing)
IP conflicts are not voodoo magic. Once the conflicting machine gets a new IP address, everything returns to normal. The network events shown in the article show that this occurs in about 1s; between the time that the interface comes up, 0.3s, and the time the interface is active, 1.3s. If this were a full negotiation, it would take around 5s.
The key thing to remember is that this shouldn't happen at all on healthy networks. So, if anyone chooses to remain opposed to this, they're saying that waiting 10s every time you wake a portable device from sleep and want to use the network connection is a worthwhile tradeoff to accommodate DHCP servers that don't respect leases and switches that can't adequately resolve an ARP entry conflict in a timely manner.
I've said it about ten times in this discussion already, but I'll keep the ten seconds (times 15-20 sleep/wake events per day) and buy decent network equipment.
So, by basic game theory, everyone implements 'asshole mode' in their devices. What happens on a technical level when every device behaves like that?
We start putting battery backup in routers so they won't drop their DHCP tables? This isn't asshole mode, it's "assume the network is functioning properly and hasn't been reset" mode. In the world of portable devices, it's important to look at where we waste time and compensating for errors is a frequent culprit.
> If you have to reboot your router frequently, you
> should replace it
No.
> but in fact a feature that Apple actually is proud of?
Not just Apple, but I imagine also Microsoft and Sun. They were so proud of it that they wrote a standards-track RFC for it: http://www.ietf.org/rfc/rfc4436.txt
And yes, they were aware of this issue:
One case where DNAv4 does increase the likelihood of an address
conflict is when:
o a DHCP server hands out an address lease,
o the host with that lease leaves the network,
o the DHCP server is power-cycled or crashes and is rebooted,
o the DHCP server, having failed to save leases to stable
storage, assigns that same address to another host, and
o the first host returns and, having a still-valid lease with
time remaining, proceeds to use its assigned address,
conflicting with the new host that is now using that same
address.
While Section 4 of the DHCP specification [RFC2131] assumes that DHCP
servers save their leases in persistent storage, almost no consumer-
grade NAT gateway does so. Short DHCP lease lifetimes can mitigate
this risk, though this also limits the operable candidate
configurations available for DNAv4 to try.
And even if it screws this up, it looks like it does a proper DHCP request about a second after the interface comes up, so the problem will be fixed quickly.
Do you have any evidence that Macs in practice tend to inadvertently boot people off the network when they join?
(and yes: some routers hold on to only a certain number of inactive leases, and routers actually do get rebooted in home, office, and hotel environments quite often, crossing the boundary of the 1-2 day leases that are often given to clients.)
Plus, this seems to produce tangibly better results in the majority of cases. It perfectly fits Apple's style of optimizing for the common use case, even if the rarer gets worse.
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 you could get away with having two devices with the same IP for a second here or there with no one the wiser.
It doesn't sound like it would be a big deal, but Windows (and Mac OS X, I've since discovered, mid-7 minute `svn commit'...) just drop the connection if there's an IP conflict. That's actually quite annoying, at the very least. You have to resubmit commits, restart getting latests, your FTP craps out halfway through, file copies go wrong, you lose your remote desktop connection, the code finishes compiling before your web page loads, etc. With any luck, you won't lose any work.
If you don't run your code on the same computer you write it on, you might be less lucky. The debugger craps out and you lose your place, or the file server goes wrong and your code gets an error and stops or whatever while you were in the middle of waiting for it to get somewhere specific. And if you use any home-written tools, they're probably going to be even less resistant to network failures of this nature than the stuff you paid for - which doesn't do a fantastic job in the first place. It all adds up.
Fortunately for me, I wasn't using Remote Desktop all that much, and the device I was working with attached via USB. And I didn't lose any work when the source control just stopped mid-operation. And I could just put headphones on, and block out my colleagues' cries of pain. So maybe that's OK then, and it's no big deal?
I'd like to be able to say what the eventual solution to the problem was, but I don't remember.
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.
If a DHCP server gives out an address, and then gives it out again before the least has expired or the first client has relinquished it, it is going to cause a conflict no matter who made the clients.
In 4 or 5 years of using OS X laptops in multiple locations (eg: private office, large corporate office with shared wifi, more hotels and airports and coffee shops than I can remember) I can't ever recall having this happen to me.
Keep in mind if aa client wants an IP, it is supposed to do DHCP discovery every time it connects to the network, even if it's lease isn't up. See http://en.wikipedia.org/wiki/Dynamic_Host_Configuration_Prot...
The DHCP will ping an address before leasing it, and if it gets a response then it will not lease that address.
"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."
"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."
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.
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?
Once the address is given out, it is the client's for the term of the lease.
Obviously, this is not realistic, and no one would ever implement a DHCP server that allowed this to happen: it is going to keep track of some fixed number of leases (probably/hopefully as many IP addresses as it is managing) and, when it runs out, it will be forced to reclaim an address from another user.
If anything, the fact that such a mechanism is not specified is simply going to make this "worse", as the specific implementation of how and when the reclamation happens is going to end up as "whatever makes sense to the guy working on that specific DHCP server implementation", and may constitute seemingly random behavior.
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.
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.
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.
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 :-)
The only conceivable grief you can put forward is that the ARP check isn't good enough. The client already owns the lease. If there's IP contention, it's because either a) it's not on the right network after all (arp check) or b) the server's fucked up and it's the servers fault (dhcp server allocated an IP twice).
Ok, so assuming the DHCP server isn't faulty may be a bit of a stretch. But coding your client to assume the server can do it's job does not deserve an "Ok, seriously?" hurf-burf post.
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.)