> Ok, seriously? That isn't a bug in an implementation somewhere,
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.
But evidently they thought it was a good trade-off, and I am inclined to agree.
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:
But evidently they thought it was a good trade-off, and I am inclined to agree.