4 ms·

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 conf

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.

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.