MAC randomisation and DHCP pools

Sten Carlsen stenc at
Mon Jul 27 17:36:36 UTC 2020

From reading the links provided by Matt, I see a somewhat better situation. Thanks Matt for providing this information.
I may not have read all the information correctly, so no guarantee.
Inline below:
Best regards 
Sten Carlsen 

For every problem, there is a solution that
is simple, elegant, and wrong.
HL Mencken

> On 27 Jul 2020, at 15.08, glenn.satchell at wrote:
> Hi Mike,
> Going back to the original question where you have a pool of 100 leases and 50 clients with a 7 day lease time. Here is what I think might happen.
> On day 1 the 50 clients each take one lease. 50 in use, 50 free.
> On day 2 the 50 clients all have a new MAC address, now we assume that once the new MAC switches over the next time the client tries to renew it will not match the old lease but will get a new lease. With a 7 day lease the usual renewal time is half way through the lease, so none of these 50 clients try to renew until 3.5 days after initially getting the lease. So no problems for days 2 or 3 until later in the day.
For IOS the MAC stays constant until it detaches from that network, so renewal is not an issue. Going away and returning later might be but then the old lease should be free - for each network the user can chose to keep a constant MAC, some will, most will not is my guess.
> So now we have 50 old leases and 50 new leases. Of course some systems may have been shutdown and released their lease, so maybe less than 50 leases in use initially so <50 old leases and 50 new leases.
> On day 4 the first few clients to renew with a new MAC address use up the previous few free leases. Other clients get "no free leases". The dhcp server can't revoke a lease it has already legitimately given to a client. I would expect this behaviour to continue until the first of the 7 day leases expire.
> Now the question is, for a client with a new MAC address, but possibly the same dhcp-identifier, will it match the existing lease? If it does match,then no problem. Behaviour will be much the same as previously.
AFAIK in the RFC, the ClientID is to main ID, MAC is not used by default, only as a second option, so fixed ID should be fine.
> The other thing with this is that if the client gets a new IP address, all existing sessions break, so apps and webpages may have to reload or may not pass authentication. So there could be a noticeable interruption.
Since at least IOS seems to keep the MAC while connected, this is not a problem, The new address comes with the next discover in dhcpd
> The above is what I think will happen based on my understanding of ISC dhcpd. I don't really know exactly how the new IOS version will behave. I would suggest setting up a trial and testing with one of these new devices and see what actually happens. There are too many variables to predict what will happen exactly.
It seems that IOS would change addresses between networks but not across renewals. That will reduce the traceability quite much with little harm. If needed the IOS can be told to not change the MAC for any particular network.
> regards,
> -glenn
> On 2020-07-27 19:34, Mike Richardson wrote:
>> On Sun, Jul 26, 2020 at 03:13:16PM -0400, Bill Shirley wrote:
>>>   Did you see my reply about:?
>>>   adaptive-lease-time-threshold       75;       # use min-lease-time when
>>>   pool is above this percent
>> I did and thanks for the information, that sounds very useful in the
>> circumstances but I'm not after a solution to a problem, I'm just trying to
>> understand the behaviour of the server in a given configuration.  I have to
>> write up a 'these are the implications' type summary to be sent to a large
>> number of different organisations and knowing what happens when using longer
>> leases will help.  I don't know their configurations and can't dictate to
>> them.  All I can do is say "if you're doing X then Y happens".
>> Thanks,
>> Mike
> _______________________________________________
> ISC funds the development of this software with paid support subscriptions. Contact us at for more information.
> dhcp-users mailing list
> dhcp-users at

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the dhcp-users mailing list