6 ms·

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.

by sedev 15y ago

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.

jarek 15y ago
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?
- tzs 15y ago
  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.
  - saurik 15y ago
    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 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.
    - brigade 15y ago
      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.
      - saurik 15y ago
        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 to go around the room finding laptops that have been setup incorrectly... the router should, and almost certainly does, just "figure something out", likely by reclaiming addresses.
  - sedev 15y ago
    That's where I'm at with this. What Jarek describes can happen, but that's a failure case, not the normal-operation case. And as portrayed in the article, the engineers at Apple have accounted for the failure case, so all's well. They simply have made the very reasonable assumption that the DHCP server will normally be operational, not in a crisis state, and that it will honor its contracts as specified in the RFC. How hard is this?
    - jarek 15y ago
      There is that principle of "conservative in what you send, liberal in what you accept" on which UNIX and half of the internet was built.
- deskamess 15y ago
  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.
  - rlpb 15y ago
    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?
    - jarek 15y ago
      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?
      - rlpb 15y ago
        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 :-)
    - hristov 15y ago
      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.
  - tzs 15y ago
    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.
- rektide 15y ago
  Please name one or more DHCP server which will knowingly violate a lease it has granted, via "kill the oldest" or any other means.
hristov 15y ago
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.
- pacala 15y ago
  The small print in paragraph 2 explicitly allows reusing the previous address until the lease expires.
  - hristov 15y ago
    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.
    - wnoise 15y ago
      This could alternately be described as "a client used its old address until it could contact the DHCP server".
- rhubarbquid 15y ago
  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 http://www.ietf.org/rfc/rfc2119.txt

by sedev 15y ago

jarek 15y ago

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?

tzs 15y ago
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.
- saurik 15y ago
  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 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.
  - brigade 15y ago
    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.
    - saurik 15y ago
      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 to go around the room finding laptops that have been setup incorrectly... the router should, and almost certainly does, just "figure something out", likely by reclaiming addresses.
- sedev 15y ago
  That's where I'm at with this. What Jarek describes can happen, but that's a failure case, not the normal-operation case. And as portrayed in the article, the engineers at Apple have accounted for the failure case, so all's well. They simply have made the very reasonable assumption that the DHCP server will normally be operational, not in a crisis state, and that it will honor its contracts as specified in the RFC. How hard is this?
  - jarek 15y ago
    There is that principle of "conservative in what you send, liberal in what you accept" on which UNIX and half of the internet was built.
deskamess 15y ago
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.
- rlpb 15y ago
  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?
  - jarek 15y ago
    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?
    - rlpb 15y ago
      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 :-)
  - hristov 15y ago
    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.
- tzs 15y ago
  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.
rektide 15y ago
Please name one or more DHCP server which will knowingly violate a lease it has granted, via "kill the oldest" or any other means.

hristov 15y ago

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.

pacala 15y ago
The small print in paragraph 2 explicitly allows reusing the previous address until the lease expires.
- hristov 15y ago
  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.
  - wnoise 15y ago
    This could alternately be described as "a client used its old address until it could contact the DHCP server".
rhubarbquid 15y ago
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 http://www.ietf.org/rfc/rfc2119.txt