Answer: Apple’s DHCP client implementation is broken and ignores aspects of the protocol when convenient, even though doing so can result in incorrect behavior.
This actually causes problems in real-world usage, because the devices will arbitrarily assume they can use an IP address that may have been reassigned. For a server with a heavily-used address pool, it’s very likely that this will happen sooner rather than later, causing inadvertent DoS of the device itself and other clients as well.
From experience, it doesn’t have that effect. I was a user, not an administrator, on a network with the same problem, so I don’t remember the specifics.
There’s also the related issue that in order to enable this behavior, the devices don’t release their leases when disconnecting from the network; this behavior is technically permissible, but very unfriendly on an address-constrained network.
Answer: Apple’s DHCP client implementation is broken and ignores aspects of the protocol when convenient, even though doing so can result in incorrect behavior.
This actually causes problems in real-world usage, because the devices will arbitrarily assume they can use an IP address that may have been reassigned. For a server with a heavily-used address pool, it’s very likely that this will happen sooner rather than later, causing inadvertent DoS of the device itself and other clients as well.
Isn’t that why it sends the arp requests? To make sure the previous address isn’t in use?
From experience, it doesn’t have that effect. I was a user, not an administrator, on a network with the same problem, so I don’t remember the specifics.
There’s also the related issue that in order to enable this behavior, the devices don’t release their leases when disconnecting from the network; this behavior is technically permissible, but very unfriendly on an address-constrained network.