|
|
|
|
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?
Thanks,
Mike
--
Mike Richardson
_______________________________________________
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
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users
|
|
|
Hi Mike,
This is not something new, it has been around since IOS 8 in 2014. I
think this page summarises how it works and has links to Apple's site
with more details.
https://9to5mac.com/2014/09/26/more-details-on-how-ios-8s-mac-address-randomization-feature-works-and-when-it-doesnt/It appears that it randomises the MAC address when the device is
passively scanning for networks and other particular settings are
enabled or disabled, so systems can't use the MAC address to
persistently track wherever you go. However, it seems that any
associations/joining of networks is based on the actual MAC address.
Or am I talking about something else entirely different?
regards,
Glenn
On 2020-07-24 19:10, 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?
>
> 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
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users
|
|
|
> Hi Mike,
>
> This is not something new, it has been around since IOS 8 in 2014. I think
> this page summarises how it works and has links to Apple's site with more
> details.
>
> https://9to5mac.com/2014/09/26/more-details-on-how-ios-8s-mac-address-randomization-feature-works-and-when-it-doesnt/>
> It appears that it randomises the MAC address when the device is passively
> scanning for networks and other particular settings are enabled or disabled,
> so systems can't use the MAC address to persistently track wherever you go.
> However, it seems that any associations/joining of networks is based on the
> actual MAC address.
>
> Or am I talking about something else entirely different?
Something new I believe:
https://wifinowglobal.com/news-and-blog/new-private-wi-fi-address-iphone-feature-could-severely-impact-the-wi-fi-industry-expert-says/?mc_cid=9ff8988c11&mc_eid=000d85d9e3https://support.apple.com/en-us/HT211227Apple, in IOS14, are going to implement the changing of MACs every 24 hours
as the default, and different ones for each SSID, I believe.
I'm just trying to evaluate the impact on things like DHCP, but I'm not sure
about exactly what happens when pools are, sort of, exhausted.
Thanks,
Mike
--
Mike Richardson
** This email address will no longer work after 30th September 2018 **
** Please use [hidden email] instead for personal email **
** For work related communication use [hidden email] **
_______________________________________________
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
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users
|
|
|
On 7/24/20 11:48 AM, [hidden email] wrote:
> This is not something new, it has been around since IOS 8 in 2014. I
> think this page summarises how it works and has links to Apple's site
> with more details.
>
> https://9to5mac.com/2014/09/26/more-details-on-how-ios-8s-mac-address-randomization-feature-works-and-when-it-doesnt/
>
>
> It appears that it randomises the MAC address when the device is
> passively scanning for networks and other particular settings are
> enabled or disabled, so systems can't use the MAC address to
> persistently track wherever you go. However, it seems that any
> associations/joining of networks is based on the actual MAC address.
On Android this has also been implemented since either 9 or 10 I think..
not 100% sure. In it the option to use the real device MAC can be chosen
on a per-network basis though. By default both the discovery and the
eventual connection have the MAC randomized. So for my DHCP server which
gives static leases based on the MAC address, making it use the real MAC
ended up being imperative. I really hope that this option will not be
removed. Development on ISC dhcp seems to have pretty much ended since
about half a year ago, so if it does get removed client-side I'd
probably have to rethink the server side.
--
Met vriendelijke groet / Best regards,
Michael De Roover
_______________________________________________
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
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users
|
|
|
The user can decide to turn the feature off on the
Apple device per WiFi network:
Rarely, a network might allow you to join with a
private address, but won't allow Internet access. If that
happens, you can choose to stop using
private addresses with that network
(https://support.apple.com/en-us/HT211227)
I agree, this will make things different, harder initially. One
example that comes to mind is white/black lists on WiFi networks,
that will go out the window.
And the other of being able to set a static IPv4 will be next to
impossible.
But was that not the point of IPv6 - totally random
In my mind this means we need an evolution of how we do things,
like how AWS/GCP have taken the classic firewall of IP/Port to a
Service Layer Firewall.
There is going to need to be another way to identify a device to
allow automatic re-authentication, like public WiFi where you
purchase access for greater then 24hrs.
How we do that, I don't know, but it's time to start thinking
about how to implement the next evolution in technology!
Thanks
Josh
On 24/7/20 20:59, Mike Richardson
wrote:
Hi Mike,
This is not something new, it has been around since IOS 8 in 2014. I think
this page summarises how it works and has links to Apple's site with more
details.
https://9to5mac.com/2014/09/26/more-details-on-how-ios-8s-mac-address-randomization-feature-works-and-when-it-doesnt/
It appears that it randomises the MAC address when the device is passively
scanning for networks and other particular settings are enabled or disabled,
so systems can't use the MAC address to persistently track wherever you go.
However, it seems that any associations/joining of networks is based on the
actual MAC address.
Or am I talking about something else entirely different?
Something new I believe:
https://wifinowglobal.com/news-and-blog/new-private-wi-fi-address-iphone-feature-could-severely-impact-the-wi-fi-industry-expert-says/?mc_cid=9ff8988c11&mc_eid=000d85d9e3
https://support.apple.com/en-us/HT211227
Apple, in IOS14, are going to implement the changing of MACs every 24 hours
as the default, and different ones for each SSID, I believe.
I'm just trying to evaluate the impact on things like DHCP, but I'm not sure
about exactly what happens when pools are, sort of, exhausted.
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
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users
|
|
|
No, the point of IPv6 is more addresses. Then the privacy
advocates and DHCP haters
jumped onboard and made IPv6 very complicated. For DHCPv6, most
devices don't
sent the host name. This makes if very hard to keep DNS updated.
However, kudos to
Microsoft because Windows does send the host name.
Yes, random MAC addresses will lead to problems assigning static
addresses. It will
be impossible to open a port (in-going or out-going) on the
firewall for a special device.
For IPv4 you can identify a device by host name because most
devices send it:
class "identify_by_hostname" {
match option host-name;
}
subclass "identify_by_hostname"
"android-4867fdc048d28c06" { ddns-hostname
"My-eXpro-tablet"; } # this works
Just add a fixed-address between the {} to the
subclass entry if desired.
Who ever comes up with this randomization stuff has obviously
never been a network administrator.
To address Mike's post, shorten your lease times:
class "mobile_device" {
match if (
option host-name ~~ "dhcpcd"
or option host-name ~~ "android"
or option host-name ~~ "iphone"
or option host-name ~~ "samsung-sm"
or option host-name ~~ "ipod"
or option host-name ~~ "ipad"
or option host-name ~~ "a?p?plewatch"
or option host-name ~~ "nintendo 3ds"
or option host-name ~~ "galaxy-"
or option host-name ~~ "g7-thinq"
or option host-name ~~ "v40-thinq"
or option vendor-class-identifier ~~
"android-dhcp"
);
#
optional: to make devices unique (for DNS) that have a
duplicate host name (users haven't changed the default):
if (lcase(option host-name) = "iphone") {
ddns-hostname = concat("iPhone-", binary-to-ascii(16, 8,
"", substring(hardware, 4, 3))); }
if (lcase(option host-name) = "iphone-2") {
ddns-hostname = concat("iPhone2-", binary-to-ascii(16, 8,
"", substring(hardware, 4, 3))); }
if (lcase(option host-name) = "iphone-3") {
ddns-hostname = concat("iPhone3-", binary-to-ascii(16, 8,
"", substring(hardware, 4, 3))); }
if (lcase(option host-name) = "ipod") {
ddns-hostname = concat("iPod-", binary-to-ascii(16, 8, "",
substring(hardware, 4, 3))); }
if (lcase(option host-name) = "ipad") {
ddns-hostname = concat("iPad-", binary-to-ascii(16, 8, "",
substring(hardware, 4, 3))); }
if ((substring(lcase(option fqdn.hostname), 0, 8) =
"g7-thinq") or (substring(lcase(option host-name), 0, 8) =
"g7-thinq")) {
ddns-hostname = concat("g7-thinq-",
binary-to-ascii(16, 8, "", substring(hardware, 4, 3)));
}
if not ((exists server.ddns-hostname) or (exists
fqdn.hostname) or (exists host-name)) {
if (substring(lcase(option
vendor-class-identifier), 0, 12) = "android-dhcp") {
ddns-hostname = concat("android-dhcp-",
binary-to-ascii(16, 8, "", substring(hardware, 4, 3)));
}
}
}
class "Other_mobile" {
match hardware;
set member_of = "mobile_device";
}
subclass "Other_mobile" 1:68:09:ff:49:0a:35; #
Brenda's-phone
subclass "Other_mobile"
1:00:aa:f6:01:05:fe { ddns-hostname "Ricks-phone"; }
.
.
subnet 192.168.99.0 netmask 255.255.255.0 {
.
.
# ------------------
pool {
allow members of "mobile_device";
allow members of "Other_mobile";
deny dynamic bootp clients;
adaptive-lease-time-threshold 75; #
use min-lease-time when pool is above this percent
min-lease-time 3600; # 1 hour
default-lease-time 14400; # 4 hours
max-lease-time 28800; # 8
hours
range 192.168.99.128
192.168.99.191; # 192.168.99.128/26 (64
addresses)
}
# ------------------
.
.
}
Note the adaptive-lease-time-threshold
statement.
Bill
On 7/24/2020 9:46 PM, Joshua Stark
wrote:
But was that not the point of IPv6 - totally random
_______________________________________________
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
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users
|
|
|
Hi Mike,
I think in the short term setting the lease time to 24 hours would free
up old leases after the MAC address changes, meaning the old client
effectively goes away. Public places like shopping malls, should already
have shorter leases due to the massive churn in clients, so it's not
going to bother them much.
But that doesn't address any of the issues with identifying individual
devices, eg to put into different classes. For that I think it will need
an education scheme with your users to turn off the feature on networks
where identifying the client matters, eg corporate or home networks.
I think this will evolve to having some other persistent identifier for
systems to use.
regards,
-glenn
On 2020-07-25 11:46, Joshua Stark wrote:
> The user can decide to turn the feature off on the Apple device per
> WiFi network:
>
> Rarely, a network might allow you to join with a private address, but
> won't allow Internet access. If that happens, you can choose to stop
> using private addresses [1] with that network
> ( https://support.apple.com/en-us/HT211227)
>
> I agree, this will make things different, harder initially. One
> example that comes to mind is white/black lists on WiFi networks, that
> will go out the window.
> And the other of being able to set a static IPv4 will be next to
> impossible.
>
> But was that not the point of IPv6 - totally random
>
> In my mind this means we need an evolution of how we do things, like
> how AWS/GCP have taken the classic firewall of IP/Port to a Service
> Layer Firewall.
> There is going to need to be another way to identify a device to allow
> automatic re-authentication, like public WiFi where you purchase
> access for greater then 24hrs.
>
> How we do that, I don't know, but it's time to start thinking about
> how to implement the next evolution in technology!
>
> Thanks
> Josh
>
> On 24/7/20 20:59, Mike Richardson wrote:
>
>>> Hi Mike,
>>>
>>> This is not something new, it has been around since IOS 8 in 2014.
>>> I think
>>> this page summarises how it works and has links to Apple's site
>>> with more
>>> details.
>>>
>>>
>>
> https://9to5mac.com/2014/09/26/more-details-on-how-ios-8s-mac-address-randomization-feature-works-and-when-it-doesnt/>>>
>>> It appears that it randomises the MAC address when the device is
>>> passively
>>> scanning for networks and other particular settings are enabled or
>>> disabled,
>>> so systems can't use the MAC address to persistently track
>>> wherever you go.
>>> However, it seems that any associations/joining of networks is
>>> based on the
>>> actual MAC address.
>>>
>>> Or am I talking about something else entirely different?
>>
>> Something new I believe:
>>
>>
> https://wifinowglobal.com/news-and-blog/new-private-wi-fi-address-iphone-feature-could-severely-impact-the-wi-fi-industry-expert-says/?mc_cid=9ff8988c11&mc_eid=000d85d9e3>> https://support.apple.com/en-us/HT211227>>
>> Apple, in IOS14, are going to implement the changing of MACs every
>> 24 hours
>> as the default, and different ones for each SSID, I believe.
>>
>> I'm just trying to evaluate the impact on things like DHCP, but I'm
>> not sure
>> about exactly what happens when pools are, sort of, exhausted.
>>
>> Thanks,
>>
>> Mike
>
>
>
> Links:
> ------
> [1] https://support.apple.com/en-us/HT211227#onoff> _______________________________________________
> 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
> [hidden email]
> https://lists.isc.org/mailman/listinfo/dhcp-users_______________________________________________
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
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users
|
|
|
Hi Glenn,
The DHCP Id should be stable, at least according to the dhcp RFC. I need
to start playing around a bit...
I do understand the privacy concerns here, and why this is being
implemented.
Cheers
Rudy
On 26-07-2020 05:02, [hidden email] wrote:
> Hi Mike,
>
> I think in the short term setting the lease time to 24 hours would
> free up old leases after the MAC address changes, meaning the old
> client effectively goes away. Public places like shopping malls,
> should already have shorter leases due to the massive churn in
> clients, so it's not going to bother them much.
>
> But that doesn't address any of the issues with identifying individual
> devices, eg to put into different classes. For that I think it will
> need an education scheme with your users to turn off the feature on
> networks where identifying the client matters, eg corporate or home
> networks.
>
> I think this will evolve to having some other persistent identifier
> for systems to use.
>
> regards,
> -glenn
>
> On 2020-07-25 11:46, Joshua Stark wrote:
>> The user can decide to turn the feature off on the Apple device per
>> WiFi network:
>>
>> Rarely, a network might allow you to join with a private address, but
>> won't allow Internet access. If that happens, you can choose to stop
>> using private addresses [1] with that network
>> ( https://support.apple.com/en-us/HT211227)
>>
>> I agree, this will make things different, harder initially. One
>> example that comes to mind is white/black lists on WiFi networks, that
>> will go out the window.
>> And the other of being able to set a static IPv4 will be next to
>> impossible.
>>
>> But was that not the point of IPv6 - totally random
>>
>> In my mind this means we need an evolution of how we do things, like
>> how AWS/GCP have taken the classic firewall of IP/Port to a Service
>> Layer Firewall.
>> There is going to need to be another way to identify a device to allow
>> automatic re-authentication, like public WiFi where you purchase
>> access for greater then 24hrs.
>>
>> How we do that, I don't know, but it's time to start thinking about
>> how to implement the next evolution in technology!
>>
>> Thanks
>> Josh
>>
>> On 24/7/20 20:59, Mike Richardson wrote:
>>
>>>> Hi Mike,
>>>>
>>>> This is not something new, it has been around since IOS 8 in 2014.
>>>> I think
>>>> this page summarises how it works and has links to Apple's site
>>>> with more
>>>> details.
>>>>
>>>>
>>>
>> https://9to5mac.com/2014/09/26/more-details-on-how-ios-8s-mac-address-randomization-feature-works-and-when-it-doesnt/
>>
>>>>
>>>> It appears that it randomises the MAC address when the device is
>>>> passively
>>>> scanning for networks and other particular settings are enabled or
>>>> disabled,
>>>> so systems can't use the MAC address to persistently track
>>>> wherever you go.
>>>> However, it seems that any associations/joining of networks is
>>>> based on the
>>>> actual MAC address.
>>>>
>>>> Or am I talking about something else entirely different?
>>>
>>> Something new I believe:
>>>
>>>
>> https://wifinowglobal.com/news-and-blog/new-private-wi-fi-address-iphone-feature-could-severely-impact-the-wi-fi-industry-expert-says/?mc_cid=9ff8988c11&mc_eid=000d85d9e3
>>
>>> https://support.apple.com/en-us/HT211227>>>
>>> Apple, in IOS14, are going to implement the changing of MACs every
>>> 24 hours
>>> as the default, and different ones for each SSID, I believe.
>>>
>>> I'm just trying to evaluate the impact on things like DHCP, but I'm
>>> not sure
>>> about exactly what happens when pools are, sort of, exhausted.
>>>
>>> Thanks,
>>>
>>> Mike
>>
>>
>>
>> Links:
>> ------
>> [1] https://support.apple.com/en-us/HT211227#onoff>> _______________________________________________
>> 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
>> [hidden email]
>> https://lists.isc.org/mailman/listinfo/dhcp-users> _______________________________________________
> 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
> [hidden email]
> https://lists.isc.org/mailman/listinfo/dhcp-users_______________________________________________
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
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users
|
|
|
Hi Rudy,
That's good to know, but bypasses all the security offered by random MAC
addresses, since a site can track using the DHCP ID :)
regards,
-glenn
On 2020-07-26 18:26, Rudy Zijlstra wrote:
> Hi Glenn,
>
> The DHCP Id should be stable, at least according to the dhcp RFC. I
> need to start playing around a bit...
>
> I do understand the privacy concerns here, and why this is being
> implemented.
>
> Cheers
>
> Rudy
>
> On 26-07-2020 05:02, [hidden email] wrote:
>> Hi Mike,
>>
>> I think in the short term setting the lease time to 24 hours would
>> free up old leases after the MAC address changes, meaning the old
>> client effectively goes away. Public places like shopping malls,
>> should already have shorter leases due to the massive churn in
>> clients, so it's not going to bother them much.
>>
>> But that doesn't address any of the issues with identifying individual
>> devices, eg to put into different classes. For that I think it will
>> need an education scheme with your users to turn off the feature on
>> networks where identifying the client matters, eg corporate or home
>> networks.
>>
>> I think this will evolve to having some other persistent identifier
>> for systems to use.
>>
>> regards,
>> -glenn
>>
>> On 2020-07-25 11:46, Joshua Stark wrote:
>>> The user can decide to turn the feature off on the Apple device per
>>> WiFi network:
>>>
>>> Rarely, a network might allow you to join with a private address, but
>>> won't allow Internet access. If that happens, you can choose to stop
>>> using private addresses [1] with that network
>>> ( https://support.apple.com/en-us/HT211227)
>>>
>>> I agree, this will make things different, harder initially. One
>>> example that comes to mind is white/black lists on WiFi networks,
>>> that
>>> will go out the window.
>>> And the other of being able to set a static IPv4 will be next to
>>> impossible.
>>>
>>> But was that not the point of IPv6 - totally random
>>>
>>> In my mind this means we need an evolution of how we do things, like
>>> how AWS/GCP have taken the classic firewall of IP/Port to a Service
>>> Layer Firewall.
>>> There is going to need to be another way to identify a device to
>>> allow
>>> automatic re-authentication, like public WiFi where you purchase
>>> access for greater then 24hrs.
>>>
>>> How we do that, I don't know, but it's time to start thinking about
>>> how to implement the next evolution in technology!
>>>
>>> Thanks
>>> Josh
>>>
>>> On 24/7/20 20:59, Mike Richardson wrote:
>>>
>>>>> Hi Mike,
>>>>>
>>>>> This is not something new, it has been around since IOS 8 in 2014.
>>>>> I think
>>>>> this page summarises how it works and has links to Apple's site
>>>>> with more
>>>>> details.
>>>>>
>>>>>
>>>>
>>> https://9to5mac.com/2014/09/26/more-details-on-how-ios-8s-mac-address-randomization-feature-works-and-when-it-doesnt/>>>>>
>>>>> It appears that it randomises the MAC address when the device is
>>>>> passively
>>>>> scanning for networks and other particular settings are enabled or
>>>>> disabled,
>>>>> so systems can't use the MAC address to persistently track
>>>>> wherever you go.
>>>>> However, it seems that any associations/joining of networks is
>>>>> based on the
>>>>> actual MAC address.
>>>>>
>>>>> Or am I talking about something else entirely different?
>>>>
>>>> Something new I believe:
>>>>
>>>>
>>> https://wifinowglobal.com/news-and-blog/new-private-wi-fi-address-iphone-feature-could-severely-impact-the-wi-fi-industry-expert-says/?mc_cid=9ff8988c11&mc_eid=000d85d9e3>>>> https://support.apple.com/en-us/HT211227>>>>
>>>> Apple, in IOS14, are going to implement the changing of MACs every
>>>> 24 hours
>>>> as the default, and different ones for each SSID, I believe.
>>>>
>>>> I'm just trying to evaluate the impact on things like DHCP, but I'm
>>>> not sure
>>>> about exactly what happens when pools are, sort of, exhausted.
>>>>
>>>> Thanks,
>>>>
>>>> Mike
>>>
>>>
>>>
>>> Links:
>>> ------
>>> [1] https://support.apple.com/en-us/HT211227#onoff>>> _______________________________________________
>>> 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
>>> [hidden email]
>>> https://lists.isc.org/mailman/listinfo/dhcp-users>> _______________________________________________
>> 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
>> [hidden email]
>> https://lists.isc.org/mailman/listinfo/dhcp-users>
> _______________________________________________
> 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
> [hidden email]
> https://lists.isc.org/mailman/listinfo/dhcp-users_______________________________________________
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
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users
|
|
|
Hi Glenn,
Would need to check the RFC, but if that remains stable on the network
it is sufficient.
This is also why i say i need to start playing/inveztigating with it.
Android10 also has this feature. Of course, the likelyhood that goodle
and Apple implement in the same way is not high :)
Cheers
Rudy
On 26-07-2020 10:50, [hidden email] wrote:
> Hi Rudy,
>
> That's good to know, but bypasses all the security offered by random
> MAC addresses, since a site can track using the DHCP ID :)
>
> regards,
> -glenn
>
> On 2020-07-26 18:26, Rudy Zijlstra wrote:
>> Hi Glenn,
>>
>> The DHCP Id should be stable, at least according to the dhcp RFC. I
>> need to start playing around a bit...
>>
>> I do understand the privacy concerns here, and why this is being
>> implemented.
>>
>> Cheers
>>
>> Rudy
>>
>> On 26-07-2020 05:02, [hidden email] wrote:
>>> Hi Mike,
>>>
>>> I think in the short term setting the lease time to 24 hours would
>>> free up old leases after the MAC address changes, meaning the old
>>> client effectively goes away. Public places like shopping malls,
>>> should already have shorter leases due to the massive churn in
>>> clients, so it's not going to bother them much.
>>>
>>> But that doesn't address any of the issues with identifying
>>> individual devices, eg to put into different classes. For that I
>>> think it will need an education scheme with your users to turn off
>>> the feature on networks where identifying the client matters, eg
>>> corporate or home networks.
>>>
>>> I think this will evolve to having some other persistent identifier
>>> for systems to use.
>>>
>>> regards,
>>> -glenn
>>>
>>> On 2020-07-25 11:46, Joshua Stark wrote:
>>>> The user can decide to turn the feature off on the Apple device per
>>>> WiFi network:
>>>>
>>>> Rarely, a network might allow you to join with a private address, but
>>>> won't allow Internet access. If that happens, you can choose to stop
>>>> using private addresses [1] with that network
>>>> ( https://support.apple.com/en-us/HT211227)
>>>>
>>>> I agree, this will make things different, harder initially. One
>>>> example that comes to mind is white/black lists on WiFi networks, that
>>>> will go out the window.
>>>> And the other of being able to set a static IPv4 will be next to
>>>> impossible.
>>>>
>>>> But was that not the point of IPv6 - totally random
>>>>
>>>> In my mind this means we need an evolution of how we do things, like
>>>> how AWS/GCP have taken the classic firewall of IP/Port to a Service
>>>> Layer Firewall.
>>>> There is going to need to be another way to identify a device to allow
>>>> automatic re-authentication, like public WiFi where you purchase
>>>> access for greater then 24hrs.
>>>>
>>>> How we do that, I don't know, but it's time to start thinking about
>>>> how to implement the next evolution in technology!
>>>>
>>>> Thanks
>>>> Josh
>>>>
>>>> On 24/7/20 20:59, Mike Richardson wrote:
>>>>
>>>>>> Hi Mike,
>>>>>>
>>>>>> This is not something new, it has been around since IOS 8 in 2014.
>>>>>> I think
>>>>>> this page summarises how it works and has links to Apple's site
>>>>>> with more
>>>>>> details.
>>>>>>
>>>>>>
>>>>>
>>>> https://9to5mac.com/2014/09/26/more-details-on-how-ios-8s-mac-address-randomization-feature-works-and-when-it-doesnt/
>>>>
>>>>>>
>>>>>> It appears that it randomises the MAC address when the device is
>>>>>> passively
>>>>>> scanning for networks and other particular settings are enabled or
>>>>>> disabled,
>>>>>> so systems can't use the MAC address to persistently track
>>>>>> wherever you go.
>>>>>> However, it seems that any associations/joining of networks is
>>>>>> based on the
>>>>>> actual MAC address.
>>>>>>
>>>>>> Or am I talking about something else entirely different?
>>>>>
>>>>> Something new I believe:
>>>>>
>>>>>
>>>> https://wifinowglobal.com/news-and-blog/new-private-wi-fi-address-iphone-feature-could-severely-impact-the-wi-fi-industry-expert-says/?mc_cid=9ff8988c11&mc_eid=000d85d9e3
>>>>
>>>>> https://support.apple.com/en-us/HT211227>>>>>
>>>>> Apple, in IOS14, are going to implement the changing of MACs every
>>>>> 24 hours
>>>>> as the default, and different ones for each SSID, I believe.
>>>>>
>>>>> I'm just trying to evaluate the impact on things like DHCP, but I'm
>>>>> not sure
>>>>> about exactly what happens when pools are, sort of, exhausted.
>>>>>
>>>>> Thanks,
>>>>>
>>>>> Mike
>>>>
>>>>
>>>>
>>>> Links:
>>>> ------
>>>> [1] https://support.apple.com/en-us/HT211227#onoff>>>> _______________________________________________
>>>> 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
>>>> [hidden email]
>>>> https://lists.isc.org/mailman/listinfo/dhcp-users>>> _______________________________________________
>>> 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
>>> [hidden email]
>>> https://lists.isc.org/mailman/listinfo/dhcp-users>>
>> _______________________________________________
>> 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
>> [hidden email]
>> https://lists.isc.org/mailman/listinfo/dhcp-users_______________________________________________
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
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users
|
|
|
> I think in the short term setting the lease time to 24 hours would free up
> old leases after the MAC address changes, meaning the old client effectively
> goes away. Public places like shopping malls, should already have shorter
> leases due to the massive churn in clients, so it's not going to bother them
> much.
Thanks for the advice but I'm really trying to understand what the behaviour
of DHCP would be in the original scenario (100 addresses, 50 clients, 7 days
lease).
> >>I'm just trying to evaluate the impact on things like DHCP, but I'm
> >>not sure
> >>about exactly what happens when pools are, sort of, exhausted.
Thanks,
Mike
--
Mike Richardson
_______________________________________________
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
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users
|
|
|
Did you see my reply about:?
adaptive-lease-time-threshold
75; # use min-lease-time when pool is above this percent
Bill
On 7/26/2020 8:40 AM, Mike Richardson
wrote:
I think in the short term setting the lease time to 24 hours would free up
old leases after the MAC address changes, meaning the old client effectively
goes away. Public places like shopping malls, should already have shorter
leases due to the massive churn in clients, so it's not going to bother them
much.
Thanks for the advice but I'm really trying to understand what the behaviour
of DHCP would be in the original scenario (100 addresses, 50 clients, 7 days
lease).
I'm just trying to evaluate the impact on things like DHCP, but I'm
not sure
about exactly what happens when pools are, sort of, exhausted.
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
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users
|
|
|
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
--
Mike Richardson
_______________________________________________
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
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users
|
|
|
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
_______________________________________________
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
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users
|
|
|
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-randomizationFor 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
_______________________________________________
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
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users
|
|
|
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
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 <a href="about:?" class="">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 [hidden email]https://lists.isc.org/mailman/listinfo/dhcp-users
_______________________________________________
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
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users
|
|
|
In reply to this post by Pallissard, Matthew-2
Re: MAC randomisation and DHCP pools
MP> As an aside,
MP> I fail to see the use case for long reservations in the first place. Lower the
MP> lease time and move on with life.
I think the question is: What's a long reservation? 7 days hardly ever seems appropriate. But the same is true for, say 2m.
If you set 10m reservations and have a problem with the DHCP server, it's going to be a *REALLY* big problem in 10m. (Oops!)
[Don't ask me how I know this! :) ]
So, I tend to pick reservation times with an eye toward giving me some breathing room should a DHCP server die or otherwise have problems.
But for pools of IP's with a lot of churn, that comes up against lease exhaustion.
There's no really great universal answer. You're right, at least on the surface, Matt - shorter reservations are helpful. But it's not a one-ended calculation - where shorter is almost universally better. It's a trade-off.
And to expand the pool of options (pun intended) - How about a bigger address pool as an option? I think in most of the cases where we're talking Wifi pools with high churn, a bigger pool isn't that hard to come by . And then, churn isn't as large a problem and super short leases aren't as critical.
_______________________________________________
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
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users
|
|
|
Thanks. That's just what I needed. The question about the fixed identifier
is interesting. If devices/DHCP use it then things won't break (as much)
but it's not exactly a great approach to privacy if the device can still be
tracked this way.
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
> _______________________________________________
> 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
> [hidden email]
> https://lists.isc.org/mailman/listinfo/dhcp-users--
Mike Richardson
** This email address will no longer work after 30th September 2018 **
** Please use [hidden email] instead for personal email **
** For work related communication use [hidden email] **
_______________________________________________
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
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users
|
|
|
On Mon, Jul 27, 2020 at 07:36:36PM +0200, Sten Carlsen wrote:
> 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.
One of the articles I posted states that the MAC will change every 24 hours,
which means that things could change mid-lease, between renewals, if
correct. The Apple site mentions 'periodically', which could mean anything
really.
Thanks,
Mike
> 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, [1] [hidden email] 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 [2]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 [3] https://www.isc.org/contact/ for more
> information.
> dhcp-users mailing list
> [4] [hidden email]
> https://lists.isc.org/mailman/listinfo/dhcp-users>
> References
>
> 1. mailto: [hidden email]
> 2. about:?
> 3. https://www.isc.org/contact/> 4. mailto: [hidden email]
> _______________________________________________
> 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
> [hidden email]
> https://lists.isc.org/mailman/listinfo/dhcp-users--
Mike Richardson
** This email address will no longer work after 30th September 2018 **
** Please use [hidden email] instead for personal email **
** For work related communication use [hidden email] **
_______________________________________________
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
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users
|
|
Locked
smime.p7s (5K)