Question about dhcp-client-identifier
perl-list at network1.net
Wed Aug 22 13:57:30 UTC 2007
Simon Hobson wrote:
>> This is ideal! If we could specify to key on hardware, would that not
>> force the DHCP server to do one of the following depending on condition:
>> 2) if the two devices are in separate physical networks, prevent one of
>> them from obtaining an IP due to: one-lease-per-client true; setting. I
>> would expect this behavior as the DHCP server would see both as the same
>> client and would deny an IP for one of the requests from the separate
> No, if they are in two different networks then the second device will
> get it's address and the lease for the first device will be
> terminated (see man dhcpd.conf). The first device will not know this
> and so will continue to use it's address until it's time to renew it.
> At this point things get interesting !
> I'm not entirely sure, but I think the server will do it's
> ping-before-offer check and find the address in use - which means it
> then marks the address as abandoned. I'm not sure if it will NAK the
> clients request or just ignore it.
> Eventually the first device will get a new address and the process
> will repeat. A similar thing will happen in the second subnet.
> After enough time, you will run out of available addresses - and have
> a fun time trying to figure out why !
Can I formally request a change in behavior then? Or perhaps a new
option? If a mac address already has a lease, it cannot obtain another
one. The behavior should be as follows:
1) if a DHCPDISCOVER comes in from the same physical network from which
the mac already has an IP address leased to it, it will be offered the
same IP again.
2) if a DHCPDISCOVER comes in from a different physical network than the
mac already has an IP address leased to it, it will be ignored (and
logged). If the device is a laptop, the user will have to be told how
to release their first IP before roaming to another network segment with
their laptop. Or, really short leases will need to be used in certain
I understand that this behavior is totally against RFC, however, in the
USA, this behavior is desirable due to CALEA. So maybe you can call it
a CALEA option? For further information regarding CALEA:
More information about the dhcp-users