Send dhcp-users mailing list submissions to
dhcp-users@lists.isc.org
To subscribe or unsubscribe via the World Wide Web, visit
https://lists.isc.org/mailman/listinfo/dhcp-users
or, via email, send a message with subject or body 'help' to
dhcp-users-requ...@lists.isc.org
You can reach the person managing the list at
dhcp-users-ow...@lists.isc.org
When replying, please edit your Subject line so it is more specific
than "Re: Contents of dhcp-users digest..."
Today's Topics:
1. Ipv6 hostname in dhclient.conf (Anjali Krishna)
2. Re: MAC randomisation and DHCP pools (glenn.satch...@uniq.com.au)
3. Re: MAC randomisation and DHCP pools (Matt Pallissard)
4. Re: MAC randomisation and DHCP pools (Sten Carlsen)
----------------------------------------------------------------------
Message: 1
Date: Mon, 27 Jul 2020 17:34:26 +0530
From: Anjali Krishna <krishnaanjal...@gmail.com>
To: dhcp-users@lists.isc.org
Subject: Ipv6 hostname in dhclient.conf
Message-ID:
<cap6u7k8pz5sd-vywknyx203brxkqkokw9oshkuxzvqtwvkd...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hi
I am using an embedded board with hostname "test_dut"[same under
/etc/hostname]. I am testing ipv6 ans ipv4 using dhcpd on server side with
- 6, - 4 options and client side I am using dhclient with - 6 and - 4
option for ipv6 and ipv4 respectively.
Both the cases Ip assignment is happening without any trouble. But in
order to extend our application feature we are providing the information of
the connected devices to the user such as mac id, ip, hostname/client name
etc. In ipv4 these information are provided under dhcpd.leases file. In
case of ipv6 I am not able to find the hostname (test_dut) under the
dhcpd6.leases files
I tried with adding various options under dhclient.conf such as send
host-name "test_dut" and edited the dhclient-script under /sbin and called
set_hostname call under bound-renew-reboot section of ipv6. Still the
server lease file is not updating the hostname for ipv6 . But hostname is
updating for ipv4 connection.
How can I resolve this issue?
Regards,
Anjali
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<https://lists.isc.org/pipermail/dhcp-users/attachments/20200727/ea3c711e/attachment-0001.htm>
------------------------------
Message: 2
Date: Mon, 27 Jul 2020 23:08:09 +1000
From: glenn.satch...@uniq.com.au
To: Users of ISC DHCP <dhcp-users@lists.isc.org>
Subject: Re: MAC randomisation and DHCP pools
Message-ID: <ab8f32d4b7c8ee06b2053173707b2...@uniq.com.au>
Content-Type: text/plain; charset=US-ASCII; format=flowed
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.
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.
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.
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.
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
------------------------------
Message: 3
Date: Mon, 27 Jul 2020 09:41:16 -0700
From: Matt Pallissard <m...@pallissard.net>
To: dhcp-users@lists.isc.org
Subject: Re: MAC randomisation and DHCP pools
Message-ID:
<20200727164116.lsdn45dh6xmfd...@matt-gen-desktop-p01.matt.pallissard.net>
Content-Type: text/plain; charset="us-ascii"
On 2020-07-24T10:10:54 +0100, Mike Richardson wrote:
> Hiya,
>
> Given Apple's decision to enable randomisation of MACs on IOS devices every
> 24 hours, I was wondering what effect this would have on DHCP?
>
> For example, if you have a pool of 100 IPs, 50 IOS devices and leases set to
> 7 days.
>
> At the moment the same 50 IPs would be assigned each day. Post-randomisation
> 50 would be assigned on day 1. On day 2, my understanding is that the devices
> would REQUEST their previous IPs and be NACKed, then do a DISCOVER and get a
> new lot of 50 addresses. What I'm unsure about is what happens on day 3? 'no
> free leases', a ping check and reallocation of old addresses or something
> else?
>
> Can anyone enlighten me?
>
To answer your question,
Yes, you'd wind up with multiple reservations per client. Options that can
help free up older leases do exist, but they aren't bulletproof. Look at
adaptive-lease-time-threshold and min-min-lease-time.
For Android, this is a non issue.
https://source.android.com/devices/tech/connect/wifi-mac-randomization
For IOS, this is configurable https://support.apple.com/en-us/HT211227. This
should be included in the profile that deploys the org's wifi settings.
As an aside,
I fail to see the use case for long reservations in the first place. Lower the
lease time and move on with life.
MAC addresses are a terrible canonical identifier, let alone an authentication
mechanism. If you need some sort of privileged access based on reservations
have users connect to a 'privileged network'. IMO a VPN is better tool for
this than a wifi network.
Matt Pallissard
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: not available
URL:
<https://lists.isc.org/pipermail/dhcp-users/attachments/20200727/d4656ea3/attachment-0001.bin>
------------------------------
Message: 4
Date: Mon, 27 Jul 2020 19:36:36 +0200
From: Sten Carlsen <st...@s-carlsen.dk>
To: Users of ISC DHCP <dhcp-users@lists.isc.org>
Subject: Re: MAC randomisation and DHCP pools
Message-ID: <5f6efbb7-12d4-44f9-a1ad-6eac45d9c...@s-carlsen.dk>
Content-Type: text/plain; charset="us-ascii"
>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.satch...@uniq.com.au 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 https://www.isc.org/contact/ for more information.
>
> dhcp-users mailing list
> dhcp-users@lists.isc.org
> https://lists.isc.org/mailman/listinfo/dhcp-users
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<https://lists.isc.org/pipermail/dhcp-users/attachments/20200727/c4001ecf/attachment.htm>
------------------------------
Subject: Digest Footer
_______________________________________________
ISC funds the development of this software with paid support subscriptions.
Contact us at https://www.isc.org/contact/ for more information.
dhcp-users mailing list
dhcp-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/dhcp-users
------------------------------
End of dhcp-users Digest, Vol 141, Issue 17
*******************************************
